On , January 13, Adam DiCarlo wrote: > Jor-el <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Debian XML/SGML <[EMAIL PROTECTED]> Home Page: <http://dulug.duke.edu/~mark/> GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
