I think I forgot to reply to this one. Mark Johnson <[EMAIL PROTECTED]> writes: > > 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:)
Lets get the Debian draft worked out and perhaps we can use role attrib plus styling to produce LSB version + Debian versions form single source. > > > > - 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:) I think this is moot because we all agreed to stick with /usr/share/sgml for now? > > 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. Hmmm. Is this true? Have you tried it? -- ...Adam Di Carlo..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
