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

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
#define XML_DEFAULT_CATALOG "/etc/xml/catalog"

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


(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 Veillard      | Red Hat Network
veillard redhat com  | libxml Gnome XML XSLT toolkit | Rpmfind RPM search engine

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]