[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: docbook-xml & centralized catalogs



Argghh. I was just about to send you the longest message I've written in
weeks and I killed the mail app. (I'm trying Evolution. FYI: C-w doesn't
mean the same as in Emacs.)

> No, I'm confused. 

Sheesh, after reading what I wrote it's no wonder you're confused.

> I suppose if I look at docbook-simplified and the
> stuff you do in there it may illuminate me?

Nope. Look at the jrefentry package, it's really simple. (2 files)

Now try to write working postinst that does the right thing. You'll see
the issue straight away.

Does it get it's own "centralized catalog" [hereafter Ccat], or does its
pointer get a file (Ccat) of it's own? 

I arbitrarily decided that the simplest policy would be: if a dtd
depends on another it's ponter goes in it's parent's Ccat. Same goes for
the flattened customizations of the parent dtd, even though they're 100%
self-contained. If we don't do domething like this, almost every dtd
will get it's own Ccat--which is totally stupid. In that case why bother
with the Ccat? Just point to the local catalog.
 
The other idea would to simply decide that all parent dtds that are not
customizations get their own Ccat file in /etc/sgml. We gotta decide
somehow... I dunno, we'll probably have to implement a fully 

> I wish you could get me on IRC and we could talk.  I'm sometimes on
> #debian-boot of Debian IRC network (and am on there now).  You'd have
> to /msg me a few time.

I'll give it a shot, but a total newbie at IRC.


> I have an alternative proposal:
> 
>  diverge even more from the spec, and leave the catalog files in the
>  dir with the materials, e.g.:
> 
> 
>   /usr/share/sgml/dtd/docbook/docbook-xml/4.1.7/catalog
>       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>       or whatever if I'm wrong here

That's almost exactly what I'm suggesting! (apart from minor path
snafus)

I'm goingto IRC now.

> I think leaving the catalog files spread around in same dir with the
> SGML/XML materials such as entities and DTDs is going to be a lot
> easier:
 >   (a) it means we can often use catalog snippets from upstream with

>   minor modifications
> 
>   (b) the /etc/sgml/catalog CATALOG directive is the place that
>   it needs to directly know the dir location, rather than every entry
>   in the catalog files themselves
> 
>   (c) the issue queried by Mark before (using a generalized "whatever
>   is the current 4.1 docbook-xml catalog) can be solved by the
>   docbook-xml/{4.1,4} symlinks technique
> 
> Thoughts?  
> I know it's a little sketchy feeling to be moving catalogs
> into the dir with entities and dtds, but I think it really is easier
> to manage, closer to upstream, etc.

Naw, it's fine. It's not windows we're dealing with...


>  And lets face it, upstream SGML
> catalogs for specific SGML/XML packages are not really user
> configuration files at all anyhow, are they?
> 
> -- 
> .....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>
> 
> 
> --  
> To UNSUBSCRIBE, email to debian-sgml-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



-- 
_____________________________________

Mark Johnson
Senior Lecturing Fellow
111 Physics Bldg., Box 90305
Department of Physics 
Duke University
Durham, NC 27708-0305
(919) 660-2504  Fax: (919) 660-2525   




Reply to: