Re: XML catalogs and xml-base
Adam DiCarlo (aph@debian.org) wrote:
> Christian Marillat <marillat.christian@wanadoo.fr> writes:
>
> > Adam DiCarlo <adam@onshored.com> writes:
> >
> > > Is anyone working on the problem of xml-base and XML catalog
> > > registration? What is the current status? Is there any way I can
> > > help?
> >
> > I've read the xml doc here (how to create xml catalog) :
> >
> > http://xmlsoft.org/catalog.html
>
> Actually the OASIS committee specification is
> <URL:http://www.oasis-open.org/committees/entity/specs/cs-entity-xml-catalogs-1.0.html>.
>
> > Then we don't need to create catalogs like we have for sgml. Catalog for
> > xml is only one file /etc/xml/catalog
>
> No, it can have delegated catalogs as well. Read on.
> >
> > The /etc/xml directory need to be shared by the new xml-base
> > package. xml-base need to contains the xmlcatalog binary (from the
> > libxml2 package) needed to register catalog.
>
> Or, xml-base could just depend on libxml2, wouldn't that be more
> robust and maintainable?
>
> Do we really need xml-base as a separate package? I think we might
> think about just extending sgml-base a bit... I'm not a big fan of
> tons of tiny packages...
Yes, I do think 'xml-base' should be a separate package. Mark Johnson has
been working on a preliminary one a couple of months back and I don't want
to go through the hassle of changing depedencies when it comes along. Now,
of course one could question whether Mark's version really is needed when
my version (see below) does what we need, but we cross that bridge when we
get there. The most important thing to clear the current messy support.
Also, to me it just makes more sense for XML stuff to depend on xml-base,
and SGML stuff on sgml-base.
> > xml-base need to share an /etc/xml/catalog file created with
> > "xmlcatalog --noout --create /etc/xml/catalog"
> >
> > Each package who provides an entry in the catalog need to add a call in
> > postinst like :
> >
> > Exemple for docbook-xml
> >
> > /usr/bin/xmlcatalog --noout --add "rewriteSystem" \
> > "http://www.oasis-open.org/docbook/xml/4.1.2"; \
> > "/usr/share/sgml/docbook/dtd/xml/4.1.2" /etc/xml/catalog
> >
> > And this call in postrm :
> >
> > /usr/bin/xmlcatalog --noout --del \
> > "http://www.oasis-open.org/docbook/xml/4.1.2";
> >
> > That's all. I don't see if we need more than that.
>
> I would prefer, and I think it's better practice, to use delegated
> catalogs. For instance, docbook-xml 4.2 includes catalog.xml and
> there's no reason I can see why I can't just use that rather than
> adding individual entities in /etc/xml/catalog for each entity.
> docbook-xml's catalog contains 8 such entities specific to that
> version, and 19 common entity references.
>
> We need to look not just at "how can it be done" but also "how can it
> best be done". By "best", I mean, the way of doing XML catalog
> registration that leads to the most robust system.
>
> Catalog delegation is better than individual entity registration
> because: (a) it's more atomic, (b) it's fewer commands to run in
> postinst/prerm, (c) less likely to leave bits lying around by accident
> after removal/upgrade, (d) allows xml packagers to use
> upstream-provided catalogs when they are available, saving a lot of
> work.
>
> Catalog delegation can be done, as I understand from reading the spec,
> by a number of different ways:
>
> - prefixing against a public identifier (delegatePublic)
>
> - prefixing against a system identifier (delegateSystem)
>
> - prefixing against an URI (delegateURI)
>
> - using nextCatalog
>
> If we are able to use the prefixing mechanisms for catalog delegation,
> that seems like it's going to be the best way, since broken delegated
> catalogs won't be used except for that type of doctypes, and thus,
> won't cascadingly break everything using /etc/xml/catalog. This would
> be a major step up from the SGML catalog system -- reference the
> recent breakage of the whole SGML catalogs for folks who installed
> xml-resume-library.
>
> Getting to the practical issues, it seems that xmlcatalog doesn't
> support all of the spec. It does support delegatePublic and
> delegateSystem; not delegateURI (is that a problem?) nor nextCatalog.
> Lack of support for nextCatalog does seem like a bit of the problem,
> e.g., for catalog delegations which cannot for some reason be
> identified by a match against a public identifier.
>
> So, in short, I counter-propose the following:
>
> sgml-base depends on libxml2
>
> sgml-base creates /etc/xml and /etc/xml/catalog, and *owns* them
>
> documentation is added to sgml-base regarding how to register XML
> catalogs, including some notes on best practices, references, and how
> to debug xml catalogs
>
> [wishlist] dh_installxmlcatalog (and dh_installsgmlcatalog for that
> matter) to manage the postinst/prerm commands using debhelper.
>
> Voila, isn't that all we need?
I'll create an 'xml-base' package which supports this. I might need
some help with the docs, though.
Thanks,
Ardo
--
Ardo van Rangelrooij
home email: ardo@debian.org
home page: http://people.debian.org/~ardo
GnuPG fp: 3B 1F 21 72 00 5C 3A 73 7F 72 DF D9 90 78 47 F9
Reply to: