Re: SGML/XML Policy Group - XML Catalog Update
Jor-el <jorel@austin.rr.com> writes:
> On Sun, 2 Jun 2002, Mark Johnson wrote:
Woah, dredging up an old one.
> > (2) A number policy decisions, (of varying priority)
> >
> > - xml catalog naming conventions
> >
> > - what, precisely, to do in the package install scripts, as far
> > as registering the resources in the catalogs. (Workable options
> > are many.)
> >
> > - whether to implement the hierarchical/cascading catalog system
> > as we did in following the LSB-SGML draft. IMO, that (i.e., the
> > current) system has too much redundancy, most of which could be
> > eliminated by using DELEGATE entries in /etc/sgml/catalog and
> > also in /etc/sgml/*.cat
I don't even quite follow this.
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
/usr/share/sgml/<pkg> is nice, the DTD vs entity split we used to
have was awkward
install-sgmlcatalog seems to work pretty wel
seems to be LSB compliant
What could be improved:
registering a bad catalog can hose the whole SGML subsystem
couldn't install-sgmlcatalog create the links under /usr/share/sgml
and include some of the catalog checking done in
/usr/share/sgml-data/sgml-catalog-check.pl ?
dh_installsgmlcatalog would be nice and might ensure greater
consistency in registration and removal
some of the terminology of supercatalog etc I find a little
confusing...
As for the actual XML plan, you should reread the discussions from
Dec. 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
Catalogs are 90% of the time going to be shipped with sources from
upstream. We should assume catalogs are upstream. Or are you talking
about higher-level catalogs which do the DELEGATion ?
> > - 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.
Splitting proper XML valid as SGML stuff into *both*
/usr/share/{sgml,xml} is going to be too much symlinking/mess.
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).
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: