Re: [xslt] XML Catalog search ordering

[Justin Fletcher <justin fletcher ntlworld com>]

In message <20010917121225.G22064@redhat.com>
   on 17 Sep 2001, you wrote:

> On Mon, Sep 17, 2001 at 04:55:36PM +0100, Justin Fletcher wrote:
> > The relevant section of the catalog is :
> >
> > <rewriteSystem systemIdStartString="http://www.movspclr.co.uk/dtd/" rewritePrefix="file:///%3CXMLCatalog$Dir%3E/gerph/"/>
> > <public publicId="-//Gerph//DTD PRM documentation 1.00//EN" uri="http://www.movspclr.co.uk/dtd/prm.dtd"/>
> >
> > and the requested identifiers are "-//Gerph//DTD PRM documentation 1.00//EN"
> > and "http://www.movspclr.co.uk/dtd/prm.dtd".
> >
> > My understanding runs thus...
> >
> > 7.1.2.1: Ok
> > 7.1.2.2: System ID was provided. No matching system entry, so skip this
> >          rule.
> > 7.1.2.3: System ID was provided. Matching rewriteSystem entry, so re-write
> >          to file:///%3CXMLCatalog$Dir%3E/gerph/prm.dtd
> >          The re-written string is returned.
> >
> > That's my understanding... There may be something else that I'm missing
> > here.
>
>   Sounds right:
>
> orchis:~/XML -> xmlcatalog --shell
> > add rewriteSystem "http://www.movspclr.co.uk/dtd/" "file:///%3CXMLCatalog$Dir%3E/gerph/"
> > add public "-//Gerph//DTD PRM documentation 1.00//EN" "http://www.movspclr.co.uk/dtd/prm.dtd"
> > dump
> <?xml version="1.0"?>
> <!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN" "http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
> <catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
> <rewriteSystem systemIdStartString="http://www.movspclr.co.uk/dtd/" rewritePrefix="file:///%3CXMLCatalog$Dir%3E/gerph/"/>
> <public publicId="-//Gerph//DTD PRM documentation 1.00//EN" uri="http://www.movspclr.co.uk/dtd/prm.dtd"/>
> </catalog>
> > resolve "-//Gerph//DTD PRM documentation 1.00//EN" "http://www.movspclr.co.uk/dtd/prm.dtd"
> file:///%3CXMLCatalog$Dir%3E/gerph/prm.dtd
> > exit
> orchis:~/XML ->
>
>   Seems to work here ... strange,

Same behaviour here, too, so my port hasn't broken those bits.

I know the /reason/; I can't say what to do about it.

In the xsltproc code we use the xsltNoNetExternalEntityLoader which we enter
with "-//Gerph//DTD PRM documentation 1.00//EN" and
     "http://www.movspclr.co.uk/dtd/prm.dtd".
This seems fine.

At the end of the routine, we have processed ID and now have a resource that
is set to "file:///%3CXMLCatalog$Dir%3E/gerph/prm.dtd". Then we hit :

    if (defaultLoader != NULL) {
	input = defaultLoader((const char *) resource, ID, ctxt);
    }

Which calls defaultLoader with "file:///%3CXMLCatalog$Dir%3E/gerph/prm.dtd",
and "-//Gerph//DTD PRM documentation 1.00//EN".

defaultLoader at this point is (or eventually calls)
xmlDefaultExternalEntityLoader - debug from that prints :

--8<--------
xmlDefaultExternalEntityLoader(file:///%3CXMLCatalog$Dir%3E/gerph/prm.dtd, xxx)
Resolve: pubID -//Gerph//DTD PRM documentation 1.00//EN
Found public match -//Gerph//DTD PRM documentation 1.00//EN
Resolve URI http://www.movspclr.co.uk/dtd/prm.dtd
--8<--------

So, it knows that we have the right URI but it has passed in the public
identifier. The public identifier is then matched with the 'public' entry in
the Catalog, and so resolves back to the http://... entry, losing the
(correctly resolved in xsltproc) file:///... entry.

I'm wondering why we try to do this resolution in xsltproc ourselves, and then
call the defaultLoader (which should always be valid because we always get
back a entity loader from libxml).

Does that make sense ?

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