Re: SGML/XML Policy Group - XML Catalog Update
On , January 13, Adam DiCarlo wrote:
> Jor-el <jorel@austin.rr.com> writes:
>
> Critiquing the existing SGML catalog registration, we find some
> problems. Maybe we can learn from this for XML and improve the
> problems too.
>
> What's good:
>
> catalog files next to their entities and DTDs that they contain
Agreed.
> /usr/share/sgml/<pkg> is nice, the DTD vs entity split we used to
> have was awkward
Agree again:)
>
> install-sgmlcatalog seems to work pretty wel
Sure, ...
> seems to be LSB compliant
Not really - see the points of departure in the old LSB-On-Debian
draft we wrote last year:
http://klecker.debian.org/~mrj/sgml-policy-draft/points-of-departure.html
AFAIK, the SGML/XML component of LSB died, anyway. So there is no
issue of LSB compliance. FWIW, I did try to get $$ to revive work on
the spec, but struck out. There's only that old, somewhat problematic
draft of a spec:
http://klecker.debian.org/~mrj/lsb-sgmlspec_cvs20020308/lsbsgml.html
I'll look into starting it up again - I happen to desperately need a
job, anyway:)
> What could be improved:
>
> dh_installsgmlcatalog would be nice and might ensure greater
> consistency in registration and removal
Agreed. We the registration tools could use a little tweaking.
> some of the terminology of supercatalog etc I find a little
> confusing...
Very much agree with you here. I've proposed some off-the-cuff
changes, but still retain the same hierarchical LSB-like structure.
Add to this the fact that the entity resolvers are forced to fully parse
many extra, irrelevant catalog files. This could cause big problems in
the future as the number of installed XML resources will likely grow
rapidly.
> As for the actual XML plan, you should reread the discussions from
> Dec.
Will do. I now have the time to catch up on this stuff, and my five
zillion ITPs and bug reports.
> Ardo and I have had some offline conversations. Too tired now
> to summarize...
>
> > > - (if applicable) whether to generate some of the xml catalogs
> > > for a given package via the postinst scripts (with
> > > /usr/bin/xmlcatalog), or to include them in the packages
Good question. Maybe leave that one up to the maintainers...
> Catalogs are 90% of the time going to be shipped with sources from
> upstream. We should assume catalogs are upstream.
Not necessarily. XSL stylesheets usually ship with no catalogs, which
makes sense given the nature of xslt. In that case, catalogs must be
constructed, whether manually by an overworked, underappreciated
maintainer, or through some nice tools called by postinst.
> Or are you talking about higher-level catalogs which do the
> DELEGATion ?
That's what I proposed - if I understand you correctly.
> > > - whether to move to a /usr/share/sgml /usr/share/xml split, as
> > > will be done with /etc/sgml and /etc/xml
>
> My feeling was that /usr/share/sgml is what is LSB and we should
> follow that, at least for any XML DTDs and entities which also are
> valid SGML. This might exclude RELAX and XML schemas, which might
> better be in /usr/share/xml.
I say put it ALL in /usr/share/xml. Nothing will break - except my
head from trying to work it all out in a sensible fashion:)
> Splitting proper XML valid as SGML stuff into *both*
> /usr/share/{sgml,xml} is going to be too much symlinking/mess.
This point I don't at all see. Why require all this cross symlinking?
Am I missing something essential here?
> Putting proper XML valid as SGML stuff into only in /usr/share/xml is
> going to break the ability to process XML with the SGML toolchain
> (jade,sp,etc etc).
I disagree. Jade, et al, don't care where things are. SGML/XML
resources are located using the existing SGML (aka TR9401) catalog
system. If the "XML valid as SGML stuff" is also registered with the
SGML catalog system there shouldn't be any problem whatsoever.
--
_____________________________________
Mark Johnson <mark@duke.edu>
Debian XML/SGML <mrj@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81
Reply to: