Christian Marillat <[EMAIL PROTECTED]> writes: > Adam DiCarlo <[EMAIL PROTECTED]> 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..<[EMAIL PROTECTED]>...<URL:http://www.onshored.com/> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
