Re: XML catalogs and xml-base
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...
> 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?
--
...Adam Di Carlo..<adam@onshore-devel.com>...<URL:http://www.onshored.com/>
Reply to: