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

[Justin Fletcher <justin fletcher ntlworld com>]

In message <20010824143149 G32662 redhat com>
          Daniel Veillard <veillard redhat com> wrote:

> On Fri, Aug 24, 2001 at 04:49:03PM +0100, Justin Fletcher wrote:
> > I know the Catalog stuff is very new, but... libxml2.4.3 xmllint.c lines
> > around 977 :
> [...]
> > Need to check if catal is NULL before operating on it. xmlLoadCatalogs will
> > do try to dereference NULL if the variable is unset. Previously this check
> > happened immediately after the option was processed, but now that processing
> > is deferred it doesn't seem to take place.
>
>   It's an evil plot to force people to switch to XML catalogs :-)

<laugh>

I was just getting used to working with SGML catalogs and now we have two
different types... Not that that's a problem or anything; I would assume
we're going to be seeing XML catalogs more often, soon ?

I do understand that it's quite new, but I've a few comments about the
current implementation.

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.

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.

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'.

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.

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.

I've looked through the source and the documentation that's about but I
didn't see any explicit answer to these questions.

> Okay, fixed, thanks !
>
> Daniel

-- 
Gerph {djf0-.3w6e2w2.226,6q6w2q2,2.3,2m4}
URL: http://www.movspclr.co.uk/
... Eyes to the heavens, screaming at the sky;
    Trying to send you messages, but choking on goodbye.