Re: [xml] libxml2 2.4.3, xmllint/catalogs bug

[Daniel Veillard <veillard redhat com>]

On Fri, Aug 24, 2001 at 09:07:21PM +0100, Justin Fletcher wrote:
> You've got the hardcoded /etc/xml/catalog as the default catalog name.
> That's probably fine for Unix-like systems, but others will not have this
> path - under RISC OS, it's a filename, not a path. If the XML_DEFAULT_CATALOG
> could be moved to libxml.h where it's used by the internal things, and then
> it might be configured more easily than changing source... It's no big deal,
> but it just makes it awkward for me.

or simply
#ifndef XML_DEFAULT_CATALOG
#define XML_DEFAULT_CATALOG "/etc/xml/catalog"
#endif

> Similarly, you use the system variables SGML_CATALOG_FILES and
> XML_CATALOG_FILES as explicit names; under RISC OS, these should be
> XML$CatalogFiles and SGML$CatalogFiles. If these were #define'd in one of the
> public headers then it would make my life a little simpler (and reduce the
> likelihood of typos.

Okay sounds fine.

> On this subject also, it seems to be the applications responsibility to set up
> SGML catalogs, but XML catalogs are set up on the initiailise call
> automatically. These seems like a strange difference. It might be just there
> for backward compatibility, but still seems 'odd'.

No there was an implementation reason, I can probably fix that now.

> I'm also a little unclear on the content of XML_CATALOG_FILES and
> SGML_CATALOG_FILES. Is this intended as a space separated list of native
> filenames of catalog files ? This is my interpretation at present.
>
> A little background for that last question might help.

  either  : or space separated will work. SGML_CATALOG_FILES env actually
comes from other exising SGML tools.

> Because RISC OS doesn't use the same name convention, internally the entire
> libxml2 engine deals with names in URI-like form, for example:
>   file:///IDEFS%3A%3AZeus/$/Files/XML/Thing.xml
> When files really need accessing, these are translated through a tiny veneer
> to RISC OS names (for example IDEFS::Zeus.$.Files.XML.Thing/xml). Since
> performing this translation is specific to the libxml2 engine port, I don't
> want to /require/ that users of the system variable adhere to the internal
> format of this particular application. More specifically, the origins and
> implementation of one engine should not be propogated through to all other
> implementors. Thus, if SGML$CatalogFiles is set to native filenames, it
> ends up reading something like :
>
>   IDEFS::Zeus.$.!BOOT.Resources.!CATALOGS.root/cat
>
> (for a single root catalog that refers to each of the individual catalogs)
>
> I'm not looking for a change to libxml2 to make it support this filename
> translation in the main distribution, because it's reasonably easy to do
> through patches at present, but I'd at least like to know that the way in
> which I'm working is compatible.

  it sounds fine, actually libxml should never handle filepaths internally
only URI-References and URIs, so yes that sounds very reasonable.
  The best way to plug your Os specific file schemes would be to simply
register an I/O handler for those, I think this can be done relatively
cleanly (i.e. without patching) except for the initial conversion of file
paths on input.

Daniel

-- 
Daniel Veillard      | Red Hat Network http://redhat.com/products/network/
veillard redhat com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/