Re: [xslt] Using catalog files on Windows

[Justin Fletcher <justin fletcher ntlworld com>]

In message <000801c1c88a$3289ac90$4c09a8c0@raven>
          Igor Zlatkovic <igor@stud.fh-frankfurt.de> wrote:

> Hi there.
>
> > > Documentation says that root XML catalog file should be in
> > > file:///etc/xml/catalog. Where is this file expected on Windows box? (I
> > > tried c:\etc\xml, but it doesn't work.)
> >
> >   Well I don't know what file:///etc/xml/catalog means on Windows ...
> > possibly \etc\xml\catalog i.e. on the same drive as the current one.
>
> Yes, if you strip the 'file://' off before passing the path to fopen, then
> it will be \etc\xml\catalog on the current drive. If you pass the whole
> thing to fopen, fopen will return NULL.
>
> >   The code of the catalog is actually libxml related not libxslt specific.
> > Igor, the Windows port maintainer, can probably enligthen us about what
> should
> > be the proper path and the associated URL.
>
> Igor, the Windows port maintainer and spare-time prophet, sees the trouble
> rolling in from the horizon :-)
>
> Unix /etc directory is a place where all system software stores its
> configuration data which is human-readable, editable with any text editor
> and if one wants the format details, typing 'man <configfile>' is sufficient
> in most cases.
>
> Windows system software prefers storing its configuration data in the system
> registry, machine-readable, editable solely through the regedit utility (or
> programming) and if one wants the format details, many hours of
> experimenting are sufficient in few cases, nothing helps in most. At least
> most things are sorted by an easy-to-remember 32-digit hexadecimal UUID :-)
>
> I can think of only one location which would be halfway Windows-apropriate
> place to store catalogs per default. There is an environment variable set by
> the system named 'CommonProgramFiles'. Per default it points to 'C:\Program
> Files\Common Files' and some rule says that people should create a
> subdirectory there and store their common data in it. This would bring us to
> 'C:\Program Files\Common Files\XML\Catalogs', as a replacement for
> /etc/xml/catalogs. Hm... A proper default fallback it is, this place, but it
> contains spaces in its path, which gives two problems. For one, trouble when

This should not be an issue, though - you just escape them as %20.

> one wants a corresponding URL. For two, this place is not static. If you use
> Windows in a language different to english, this place has a different name,
> it is translated. In addition to that, Admin can put it where she pleases.
> Hardcoding it won't help, one must read the environment variable to find out
> where it actually is.

This, too, shouldn't (IMO) be a problem; certainly calling getenv at
environment start to read its location is reasonably simple, or embedding it
directly in the filename that is used by default.

My RISC OS port actually takes the XML$CatalogFiles (or SGML$CatalogFiles)
system variable and processes them into URI-like forms so that they can be
given as native filenames and it's only the libxml2 code that sees them in
URI-like forms. I could quite equally have set them to (wait for it, it's
evil) :

file:///%3CXMLCatalog%24Dir%3E/root.xml

Which maps to the native filename :
  <XMLCatalog$Dir>.root/xml

The <> specifiers indicate that an environment variable substitution should
occur; this is performed at the filesystem level, not at the application
level. It's not quite the same as unix, but similar to using
$XML_CATALOG_DIR/root.xml at a shell. One would imagine that one of these
two methods - or any number of others - can be used to locate a directory.

> >   Well you can try to guess the valid filename or URL which will work
> > and set them as environment variables SGML_CATALOG_FILES or
> XML_CATALOG_FILES
> > The routine will end up using open() to load the file.
>
> This is good. I would suggest using these environment variables. Doing a
>
>   set XML_CATALOG_FILES=%CommonProgramFiles%\XML\Catalogs
>
> would be a simple solution with the lowest degree of trouble. This would
> place things where they belong and work, even if one must install this on
> thousands of clients with different CommonProgramFiles location.

Could this not just be the default value used by the libxml2 engine if the
variable isn't set ?

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