Formation of SGML/XML Policy Group

[Mark Johnson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Hi Manoj,

I'm thinking it'd make good sense to make some sort of official policy
document, with associated author group, to compose a new Debian policy
for packaging, implementation, etc., of XML, SGML, and related stuff.

Although Adam DiCarlo & I started something about a year ago[1] in an
effort to develop an LSB-compliant implementation, the document isn't
finished. Nor can it be, since parts of the current LSB-XML/SGML draft
spec are either unimplementable, or unfinished.

I haven't a clue how to make this happen, which is why I'm writing
you.

Furthermore, it's looking likely that the LSB-XML/SGML project will
re-form as a FreeStandards Working Group, and that I will serve as
Director of the project. (Startup in a month or so.)

So, this time around Debian will definitely be in the loop on the spec
development - which was not really the case in the previous round.

Ardo also suggested that we develop some group package management
system, with the maintainer being some alias like
'***@debian.org', and add maintainers to the list who can
upload on behalf of '***@debian.org'.

Let know your thoughts on these issues. It'd be a good idea to start
getting this structure into place.

Thanks,
Mark

[1] http://people.debian.org/~mrj/sgml-policy-draft/

_____________________________________
Mark Johnson <***@duke.edu>
Debian SGML <***@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.6 <http://mailcrypt.sourceforge.net/>

iQEeBAEUAwAGBQI80WPGAAoJELy8ssgr4v6B9mMD/A8jOtcNj1J3ejNvRftcwKUf
J2QQA60dYuejSc6vb1PfckQolaihB52cyZPUfxx+ZG7Y/Zhl1E9YbuxIohnim7bl
5Br7RFDr1BqKa6Uiafj7x4aWp/g09G8ku8KefRSW6e42A35dbqbIs2PO61VSoqED
SoipIjLBcJ0Om/dP2L0jA/9YRzb5J+oudCBTaUooh7MA4uGc5PUyymSOcFLdlkbC
iLNNO6vnHabkmYj8U88PpYToNkrV89lqxbRybmSFkWSzeydeSAuzM3DrXnRpQ2Rq
4VVKkDqO+uq8c66mVe+ZN9qU/cnPhFPHsLLoVVlezaui9oB9fNPIJU0E/xOudcsG
0g==
=Cv6w
-----END PGP SIGNATURE-----

[Manoj Srivastava]

Mark> I'm thinking it'd make good sense to make some sort of official policy
Mark> document, with associated author group, to compose a new Debian policy
Mark> for packaging, implementation, etc., of XML, SGML, and related stuff.

Mark> I haven't a clue how to make this happen, which is why I'm writing
Mark> you.

I would leave the composition of this group to the experts we

Mark> Ardo also suggested that we develop some group package management
Mark> system, with the maintainer being some alias like
Mark> '***@debian.org', and add maintainers to the list who can
Mark> upload on behalf of '***@debian.org'.

Umm. The way it generally happens is that the group of
experts, and the package maintainers of related packages, come up
with a working policy. Then comes a testing phase, during which the
policy is either a part of some package, or is a separate package by
itself, and may be referred to in the policy document as a
recommendation.

Finally, when things settle down, and the new subpolicy does
not change, it is subsumed into the actual policy package, and is
distributed as official policy; from that point on generic policy
change protocol has to be followed to amend the document.

Does this clarify things?

manoj
--
Luck, that's when preparation and opportunity meet. P.E. Trudeau
Manoj Srivastava <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Mark Johnson]

Post by Manoj Srivastava
Mark> I'm thinking it'd make good sense to make some sort of official policy
Mark> document, with associated author group, to compose a new Debian policy
Mark> for packaging, implementation, etc., of XML, SGML, and related stuff.
Mark> I haven't a clue how to make this happen, which is why I'm writing
Mark> you.
I would leave the composition of this group to the experts we

I agree. And that group would be us: the ones who
package/develop/implement the xml/sgml stuff. In other words, the
people I cc'd on this message, plus a few others.

Post by Manoj Srivastava
[...] The way it generally happens is that the group of experts,
and the package maintainers of related packages, come up with a
working policy. Then comes a testing phase, during which the policy
is either a part of some package, or is a separate package by
itself, and may be referred to in the policy document as a
recommendation.

Sounds to me like you're telling us to keep on doing what we're
doing. Then, at some point, we declare it to be sufficiently finished
and include or package it separately.

In the meantime, there isn't anything official. The closest being the
draft from last spring:

http://people.debian.org/~mrj/sgml-policy-draft/

Post by Manoj Srivastava
Finally, when things settle down, and the new subpolicy does
not change, it is subsumed into the actual policy package, and is
distributed as official policy; from that point on generic policy
change protocol has to be followed to amend the document.
Does this clarify things?

Kind of. But I can tell you that it'll be at least a year before the
SGML/XML policy becomes anything near stable. It has to track LSB,
which is currently up in the air.

I guess we'll just keep on keepin' on, and make the big announcement
when the time comes.

Thanks muchly,
Mark

_____________________________________
Mark Johnson <***@duke.edu>
Debian SGML <***@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81

[Manoj Srivastava]

Mark> Sounds to me like you're telling us to keep on doing what we're
Mark> doing. Then, at some point, we declare it to be sufficiently
Mark> finished and include or package it separately.

And only you guys can reach that determination

Mark> In the meantime, there isn't anything official. But I can tell
Mark> you that it'll be at least a year before the SGML/XML policy
Mark> becomes anything near stable. It has to track LSB, which is
Mark> currently up in the air.

Mark> I guess we'll just keep on keepin' on, and make the big announcement
Mark> when the time comes.

Well, I am open to suggestions. What else may one do?

manoj
--
Go out and tell a lie that will make the whole family proud of
you. Cadmus, to Pentheus, in "The Bacchae" by Euripides
Manoj Srivastava <***@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C

[Adam Di Carlo]

Mark, can you clarify what is the todo list for the Debian SGML/XML
policy?

[Mark Johnson]

Post by Adam Di Carlo
Mark, can you clarify what is the todo list for the Debian SGML/XML
policy?

Be kind - what follows is off the top of my head...

(1) First would be a working implementation of xml catalogs.

I'm working on this and have made a few test 'xml-base'
packages. The package is based on what Daniel Veillard and Tim
Waugh have been doing in RedHat - and it works. (I'm trying not to
introduce any pieces that depart from what redhat's doing.)

After further testing, and some policy discussion regarding the
details of registering resources, I plan to upload the package
within a day or two.

The package sets up an initial xml catalog: /etc/xml/catalog,
provides dtds for composing valid catalog files, and includes the
OASIS XML Catalog spec & OASIS tr9401:1997 specs as part of the
package docs.

It also will have a brief primer on how to register xml resources
in existing packages, in the interim. The primer should be of use
until all xml-related packages are updated and can register their
own resources. This will depend on stuff below.

(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

- (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

- whether to move to a /usr/share/sgml /usr/share/xml split, as
will be done with /etc/sgml and /etc/xml


I'm sure there's more, but I wanted to make a post to reassure
everyone that the xml catalog problem is being addressed most
expeditiously.

I need to get away from the computer for a few hours and map all of
this out. When I do, I'll post a message with specific suggestions &
rationale for some of this stuff. I'll start a draft doc for xml
catalog implementation.

Don't want to go too far beyond this until I know how/if the LSB-XML/SGML
Working Group is going to work out.


Cheers,
Mark
--
_____________________________________
Mark Johnson <***@duke.edu>
Debian SGML <***@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81

[Ian Zimmerman]

Mark> - whether to move to a /usr/share/sgml /usr/share/xml split, as
Mark> will be done with /etc/sgml and /etc/xml

I hope backward compatibility with the current setup will be
maintained, in the sense that xml resources will still be available
via the sgml catalogs (apart from going into the xml catalogs, if
desired).

hint: jade is nonstandard as a XML processor, but it works.

[Gregory Leblanc]

On Sun, 2002-06-02 at 20:53, Ian Zimmerman wrote:
Mark> - whether to move to a /usr/share/sgml /usr/share/xml split, as
Mark> will be done with /etc/sgml and /etc/xml

I hope backward compatibility with the current setup will be
maintained, in the sense that xml resources will still be available
via the sgml catalogs (apart from going into the xml catalogs, if
desired).

hint: jade is nonstandard as a XML processor, but it works.

Yeah, I'd expect that any XML resources currently available via the SGML
catalogs to stay around. However, newer XML resources, especially those
using newer XML features may NOT be SGML, thus meaning that they
shouldn't get registered in the SGML catalogs. If Mark asks me
questions about that on IRC, that's about the answer I'll give him. :)
Greg

[Mark Johnson]

Post by Ian Zimmerman
Mark> - whether to move to a /usr/share/sgml /usr/share/xml split, as
Mark> will be done with /etc/sgml and /etc/xml
I hope backward compatibility with the current setup will be
maintained, in the sense that xml resources will still be available
via the sgml catalogs (apart from going into the xml catalogs, if
desired).

Naturally, we'll keep compatability. The simple way to think about it
is that we're adding, not replacing a catalog system. And the XML
resources will then get registered in both catalog systems. (FWIW,
not all XML resources can be regisitered in the SGML catalogs, but
this fact doesn't backward compatability in the sense you speak of.

There are no plans at all to ditch the SGML catalogs. Nor jade, for
that matter. To each, his own.

Of course I'm only paraphrasing what greg would've told me on IRC, had
I'd asked him.

Post by Ian Zimmerman
hint: jade is nonstandard as a XML processor, but it works.

Yep, jade does a fine job of transforming XML documents using DSSSL
stylesheets. I use it all the time.

Cheers,
Mark

Post by Ian Zimmerman
Yeah, I'd expect that any XML resources currently available via the SGML
catalogs to stay around. However, newer XML resources, especially those
using newer XML features may NOT be SGML, thus meaning that they
shouldn't get registered in the SGML catalogs. If Mark asks me
questions about that on IRC, that's about the answer I'll give him. :)
Greg
--
Portland, Oregon, USA.
Please don't copy me on replies to the list.

--
_____________________________________
Mark Johnson <***@duke.edu>
Debian SGML <***@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81

[Adam Di Carlo]

Mark, how goes the XML catalog effort? Anything I can do to help?

Are there any examples about how XML catalogs work? I know
scrollkeeper want them, and Christian (the scrollkeeper maintainer) is
bugging me for them.

[Eric Baudais]

Post by Adam Di Carlo
Mark, how goes the XML catalog effort? Anything I can do to help?
Are there any examples about how XML catalogs work? I know
scrollkeeper want them, and Christian (the scrollkeeper maintainer) is
bugging me for them.

What type of examples do you want? The commands to make an XML Catalog,
its practical uses, or the catalog files themselves?
http://xmlsoft.org/catalog.html contains a little bit of each of those.
If you want more detailed examples please be a bit more specific.

Eric Baudais

[Christian Marillat]

Post by Adam Di Carlo
Mark, how goes the XML catalog effort? Anything I can do to help?
Are there any examples about how XML catalogs work? I know
scrollkeeper want them, and Christian (the scrollkeeper maintainer) is
bugging me for them.
What type of examples do you want? The commands to make an XML Catalog,
its practical uses, or the catalog files themselves?
http://xmlsoft.org/catalog.html contains a little bit of each of those.
If you want more detailed examples please be a bit more specific.

We only need a policy to add/remove catalog.

Christian

[Jor-el]

Post by Mark Johnson
(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
- (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
- whether to move to a /usr/share/sgml /usr/share/xml split, as
will be done with /etc/sgml and /etc/xml

Mark,

Glad you are active again - and Happy Birthday! In addition to the
above items, could you also please consider a SYSTEM local location for
the dtd that defines XML Catalog documents? While xsltproc doesnt
reference the 'net for this DTD when it uses the catalogs, that is not to
say that there wont be another XSL processor or other XML programs that
need to reference this DTD.

Thanks,
Jor-el

[Mark Johnson]

Post by Jor-el
Glad you are active again - and Happy Birthday!

Glad to be back -- and thanks. Divorce sucks, and not in a good way:)

Post by Jor-el
In addition to the above items, could you also please consider a
SYSTEM local location for the dtd that defines XML Catalog
documents?

Sure. It'd naturally have to be part of xml-base. Also, I've written a
customization layer for the XML Catalog spec dtd that provides support
for directives from the previous OASIS TR9401 (aka SGML) catalog
spec. This should make the conversion from TR9401 to XML Catalog
entries a bit easier.

The dtds and the content models can be seen at one of the following:

http://klecker.debian.org/~mrj/oasis/catalog/xml/

http://globaltranscorp.org/oasis/catalog/xml/

Keep in mind that Norm still has to sign off on the use of elements in
his urn namespace, as well as giving the OK to the OASIS-based FPIs
I've constructed. And also that the content of the dtds reflect the
content of the August 2001 XML Catalog spec, rather than the Oct 2002
version. (I'll have to look into the differences...)

When all is said and done, I think Debian is also going to need to
provide network-accessible dtds (if we already don't), by defining a
special subdir on a debian webserver. In this way we can provide
persistent URLs for debian-specific dtds and other xml resources (such
as stylesheet customizations, etc.)

Something along the lines of "http://www.debian.org/xml/..." ought to
suffice.

Anyway, those are some general thoughts.

Delusional as I am, I believe the catalog structure/content policy (as
in what elements should be allowed in which level catalogs) that I'll
propose tomorrow makes good sense in that it minimizes parsing of
catalogs so that the _only_ catalog that gets fully parsed is exactly
the catalog that is needed. (Modulo things I've missed, of course.)

More later...

Cheers,
Mark

Post by Jor-el
While xsltproc doesnt reference the 'net for this DTD when it uses
the catalogs, that is not to say that there wont be another XSL
processor or other XML programs that need to reference this DTD.

...which is why I think it also makes sense to put the dtds on the
web...

Post by Jor-el
Thanks,
Jor-el
--

[Ardo van Rangelrooij]

Post by Mark Johnson

Post by Jor-el
Glad you are active again - and Happy Birthday!

Glad to be back -- and thanks. Divorce sucks, and not in a good way:)

Welcome back. I was already wondering what happened but the above
explains it all. Anyway, happy birthday!

Post by Mark Johnson

Post by Jor-el
In addition to the above items, could you also please consider a
SYSTEM local location for the dtd that defines XML Catalog
documents?

Sure. It'd naturally have to be part of xml-base. Also, I've written a

In case you haven't noticed yet, the name 'xml-base' is not really a
good name anymore, since there is already an "XML Base" (see
http://www.w3.org/TR/xmlbase/). Hence, we came up with the name
'xml-common' which is the same name RH uses.

Thanks,
Ardo

[Jor-el]

Post by Mark Johnson

Post by Jor-el
SYSTEM local location for the dtd that defines XML Catalog
documents?

Sure. It'd naturally have to be part of xml-base. Also, I've written a
customization layer for the XML Catalog spec dtd that provides support
for directives from the previous OASIS TR9401 (aka SGML) catalog
spec. This should make the conversion from TR9401 to XML Catalog
entries a bit easier.
http://klecker.debian.org/~mrj/oasis/catalog/xml/

Mark,

I took a look at the documents, above. What is the value in having
the tr9401.dtd? The elements in an SOC catalog which have no equivalent in
an XML Catalog should rightly be thrown away IMHO. SGML processors arent
going to handle XML catalogs - which leaves only XML-based-technology
processors using XML catalogs and so I fail to see the value in these
elements. If you disagree, you'll have to enlighten me as to why.

Post by Mark Johnson
When all is said and done, I think Debian is also going to need to
provide network-accessible dtds (if we already don't), by defining a
special subdir on a debian webserver. In this way we can provide
persistent URLs for debian-specific dtds and other xml resources (such
as stylesheet customizations, etc.)
Something along the lines of "http://www.debian.org/xml/..." ought to
suffice.

Good idea.

Post by Mark Johnson

Post by Jor-el
While xsltproc doesnt reference the 'net for this DTD when it uses
the catalogs, that is not to say that there wont be another XSL
processor or other XML programs that need to reference this DTD.

...which is why I think it also makes sense to put the dtds on the
web...

Well...yes. But it is also important to have the DTDs available
locally so that a machine that is not on the internet can process XML
documents. I think you agree with me on this, but I'm not a 100% sure -
hence the repetition.

Regards,
Jor-el

[Adam DiCarlo]

Post by Mark Johnson
Sure. It'd naturally have to be part of xml-base. Also, I've written a
customization layer for the XML Catalog spec dtd that provides support
for directives from the previous OASIS TR9401 (aka SGML) catalog
spec. This should make the conversion from TR9401 to XML Catalog
entries a bit easier.

Which directives are missing that you considered desirable?

Why is conversion from TR9401 to XML catalogs something we should
worry about? Seems like extra work given that most software will ship
with XML catalogs anyhow.

Are we going to be tightly constrained by what directives in XML
catalogs are currently understood by the tools?

Remember, we're the integrators, not the people maintaining the
tools. We do rather have to follow the limitation of current
tools...

Post by Mark Johnson
When all is said and done, I think Debian is also going to need to
provide network-accessible dtds (if we already don't), by defining a
special subdir on a debian webserver. In this way we can provide
persistent URLs for debian-specific dtds and other xml resources (such
as stylesheet customizations, etc.)
Something along the lines of "http://www.debian.org/xml/..." ought to
suffice.

Ok, you should qualify this by saying that any Debian-specific XML
stuff would need this treatment. There's no need to provide a stable
network URL for things that are shipped by other folks, and we don't
really have the manpower to make that commitment anyhow.

But is there any Debian-specific XML customizations or DTDs or
entities or anything yet?

Post by Mark Johnson
Anyway, those are some general thoughts.
Delusional as I am, I believe the catalog structure/content policy (as
in what elements should be allowed in which level catalogs) that I'll
propose tomorrow makes good sense in that it minimizes parsing of
catalogs so that the _only_ catalog that gets fully parsed is exactly
the catalog that is needed. (Modulo things I've missed, of course.)

Ok, I'll have to wait for what you're going to send, but I already
shuddering. It seems like a lot of work. My approach is to do as
little work as possible -- we have plenty of things to do and don't
need to invent new technologies, IMHO.

I think what Ardo is trying to do, and which I agree with, is to adapt
the update-catalog tool from the Gnome XML tools and adapt that with
as thin a shim as possible for the purposes of centralized XML catalog
registration. This would be pretty much as good, but not much better,
than the SGML catalog registration. But, IMHO, the existing SGML
catalog registration is good enuf (at least, for a first pass).

[Ben Finney]

Howdy all,

I'm trying to address Bug#550052, so please keep that bug report
included in any relevant response from this.

In short: the ‘tr9401.dtd’ in the ‘w3c-dtd-xhtml’ package is catalogued
with a canonical URL that no longer resolves.

Post by Mark Johnson
http://klecker.debian.org/~mrj/oasis/catalog/xml/
http://globaltranscorp.org/oasis/catalog/xml/

No longer. The former times out, the latter domain doesn't resolve in DNS.

What should be the canonical URL for the ‘tr9401.dtd’ document?

Post by Mark Johnson
I took a look at the documents, above. What is the value in having
the tr9401.dtd? The elements in an SOC catalog which have no equivalent in
an XML Catalog should rightly be thrown away IMHO. SGML processors arent
going to handle XML catalogs - which leaves only XML-based-technology
processors using XML catalogs and so I fail to see the value in these
elements. If you disagree, you'll have to enlighten me as to why.

I didn't see a response to that. Is there value to Debian in having the
‘w3c-dtd-xhtml’ package incorporate this document?


To address this bug I'd like to either find a justification for removing
the ‘tr9401.dtd’ document (and a mechanism for dropping it cleanly), or
find a reliable canonical URL for it.

[Adam DiCarlo]

Woah, dredging up an old one.

Post by Mark Johnson
(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...

Post by Mark Johnson
- (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 ?

Post by Mark Johnson
- 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).

[Mark Johnson]

Post by Adam DiCarlo
Critiquing the existing SGML catalog registration, we find some
problems. Maybe we can learn from this for XML and improve the
problems too.
catalog files next to their entities and DTDs that they contain

Agreed.

Post by Adam DiCarlo
/usr/share/sgml/<pkg> is nice, the DTD vs entity split we used to
have was awkward

Agree again:)

Post by Adam DiCarlo
install-sgmlcatalog seems to work pretty wel

Sure, ...

Post by Adam DiCarlo
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:)

Post by Adam DiCarlo
dh_installsgmlcatalog would be nice and might ensure greater
consistency in registration and removal

Agreed. We the registration tools could use a little tweaking.

Post by Adam DiCarlo
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.

Post by Adam DiCarlo
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.

Post by Adam DiCarlo
Ardo and I have had some offline conversations. Too tired now
to summarize...

Post by Mark Johnson
- (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...

Post by Adam DiCarlo
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.

Post by Adam DiCarlo
Or are you talking about higher-level catalogs which do the
DELEGATion ?

That's what I proposed - if I understand you correctly.

Post by Adam DiCarlo

Post by Mark Johnson
- 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:)

Post by Adam DiCarlo
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?

Post by Adam DiCarlo
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.

[Adam DiCarlo]

I think I forgot to reply to this one.

Post by Mark Johnson

Post by Adam DiCarlo
seems to be LSB compliant

Not really - see the points of departure in the old LSB-On-Debian
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
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.

Post by Mark Johnson

Post by Adam DiCarlo

Post by Mark Johnson
- 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?

Post by Mark Johnson

Post by Adam DiCarlo
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?

[Mark Johnson]

Post by Adam DiCarlo

Post by Mark Johnson

Post by Adam DiCarlo
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?

Yep. Way.

Post by Adam DiCarlo
Have you tried it?

Yep. Works like crazy, too. In fact, I make use of this feature on a
daily basis.

You see, I have my own personal version of xml-base that includes the
DTD for XML Catalogs...

Here's a working example from my xml-base package:

a. I put the XML Catalog DTD and its accompanying SGML catalog in
/usr/share/xml/dtd/,

b. added a "Centralized Catalog" /etc/sgml/xml-base.cat, and

c. registered it in /etc/sgml/catalog.


Here's the contents of /etc/sgml/xml-base.cat:
**********************************************
--
## ======================================================================
## /etc/sgml/xml-base.cat : SGML centralized catalog
## ======================================================================
## Please use update-catalog(8) to modify this file.
## ======================================================================
--

CATALOG "/usr/share/xml/dtd/catalog"
DOCTYPE catalog "/usr/share/xml/dtd/catalog.dtd"

**********************************************

Now, when I fire up emacs to edit an xml catalog, nsgmls has no problem
finding the XML Catalog DTD. It uses the DOCTYPE directive to find
it.

Here's the entity lookup log:
*******************************************************************
Start looking for dtd entity catalog public -//OASIS//DTD XML Catalogs V1.0//EN// system http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd
catalog: /etc/sgml/catalog exists
catalog: /etc/sgml/xml-base.cat exists

Post by Adam DiCarlo

Post by Mark Johnson
/usr/share/xml/dtd/catalog.dtd [by doctype catalog]

*******************************************************************

And finally, here's the relevant part of the xml catalog file I'm
editing:
***************************************************************
<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD XML Catalogs V1.0//EN"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">

[...catalog stuff...]

</catalog>
***************************************************************

I kid you not, this works just fine. Location of resources doesn't
matter, so long as the location is contained in the catalog that is
parsed.

I'm surprised that you find this surprising:)

Whattya think of that?

Mark

[Adam DiCarlo]

Post by Mark Johnson
I'm surprised that you find this surprising:)

Actually it makes sense. I used to know this but when I gave up
maintaining jade/openjade I forgot it all.

The only thing that would break would be relative system references in
documents which assume prefix of /usr/share/sgml, but I would guess
that is rather rare.

Anyhow -- are we going to ignore /usr/share/xml or embrace it? Last I
heard we're waiting for FHS to opine on the matter, and until then,
stick with /usr/share/sgml. I personally don't much see the point of
a separate /usr/share/xml but I'm known as something of a fuddy-duddy.

[Ian Zimmerman]

Adam> Anyhow -- are we going to ignore /usr/share/xml or embrace it?
Adam> Last I heard we're waiting for FHS to opine on the matter, and
Adam> until then, stick with /usr/share/sgml. I personally don't much
Adam> see the point of a separate /usr/share/xml but I'm known as
Adam> something of a fuddy-duddy.

For what my vote is worth - I say stay with /usr/share/sgml.

[Mark Eichin]

FYI, "thot.org" is someone else (and I'm already on debian-sgml.)

This does seem like the kind of thing that needs a focus-person
(serving as document editor but also has "driver" in terms of figuring
out what needs doing an asking for help or at least argument or
consensus on those bits...) rather than yet-another-list. I'd
actually expect most-if-not-all of the discussion to belong on
debian-sgml.

Do I understand correctly that the long-term goal here is to have high
quality XML/SGML support in LSB? With Debian as the "testbed" in the
sense that we're closest to having something useful and would thus be
the most effective contributors, and as a side effect would help
formalize and "flesh out" the Debian XML/SGML support as well?

[Mark Johnson]

Post by Mark Eichin
FYI, "thot.org" is someone else (and I'm already on debian-sgml.)

Sorry about that. I made the mistake of using my organic storage
device to recall your address - my brain.

Post by Mark Eichin
This does seem like the kind of thing that needs a focus-person
(serving as document editor but also has "driver" in terms of figuring
out what needs doing an asking for help or at least argument or
consensus on those bits...) rather than yet-another-list.

Yep, the editor would really play an essential role in this.

I certainly wasn't at all advocating the creation of a new list.

Post by Mark Eichin
I'd actually expect most-if-not-all of the discussion to belong on
debian-sgml.

Agreed.

Post by Mark Eichin
Do I understand correctly that the long-term goal here is to have high
quality XML/SGML support in LSB?

Yep. And also the converse: That high-quality implementations will
help drive the formation of an intelligent spec. Hopefully, we'll be
one of those.

Post by Mark Eichin
With Debian as the "testbed" in the sense that we're closest to
having something useful and would thus be the most effective
contributors,

You're exposing your Debian bias, here:-) Quite understandable, IMO.

However, I'm not so sure that your statement about debian being
closest to having something useful is necessarily true anymore. SuSE,
Mandrake, and Redhat all have working setups. Of course, they all have
bugs too, just like we do.

Post by Mark Eichin
and as a side effect would help formalize and "flesh
out" the Debian XML/SGML support as well?

Exactly.

The best way to ensure that the situation unfolds in this way would be
for you (and other debian xml/sgml developers) to join the
soon-to-be-formed LSB-xml-sgml Working Group.

You can do so by responding to the RFC I posted at:

https://lists.dulug.duke.edu/pipermail/lsb-xml-sgml/2002-April/000228.html

(But please reply to the list via <lsb-xml-***@dlug.duke.edu>, and
not to me.)

The main points your post should make are:

- you support the formation of the Working Group operating
under a well-defined process policy (such as the draft
"Proposed Process Model' I point to.)

- you intend to participate in the developoment of the
specification as Debian representative.


BTW, I've already submitted the proposal for formation of the WG to
the Free Standards Group, and am waiting to hear back.

Cheers,

Mark "more than you asked for" Johnson
--
_____________________________________
Mark Johnson <***@duke.edu>
Debian SGML <***@debian.org>
Home Page: <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81