Re: [xml] setting URL for xmlRelaxNGParserCtxt?

[Martijn Faassen <faassen infrae com>]

Daniel Veillard wrote:
> On Wed, Jan 26, 2005 at 12:07:50AM +0100, Martijn Faassen wrote:
>
> > Daniel Veillard wrote:
> >
> > > no the base has to be set in the document. Since that part is just
> > > described by '...' in your mail there is little more indications I can
> > > provide.
> >
> > Interesting. This is how a doc typically get parsed now:
> >
> > pctxt = xmlNewParserCtxt()
> > .. (share dictionaries)
> > result = xmlCtxtReadFile(pctxt, filename,
> >                                   NULL, _getParseOptions())
>
>
>    Okay, looks good.

Hm.. The URL is indeed set in the document, and the scenario with moving 
nodes didn't take place in this case, but it doesn't work correctly. If 
I start the program in the same directory as the place the .rng file is 
stored, the include file is successfully loaded. If I however start it 
from a lower directory, it will fail because the include cannot be found.

Given a directory foo with in it:

one.rng [<include href="two.rng"/>]
two.rng

if I load up things from the directory foo, it'll work. The URL of the 
xmlDoc of one.rng will be "one.rng". If I load up things from the 
directory one above foo, the URL of one.rng will be "foo/one.rng", and 
things will fail:

I/O warning : failed to load external entity "test2.rng"
element include: Relax-NG parser error : xmlRelaxNG: could not load 
test2.rng
element include: Relax-NG parser error : Failed to load include test2.rng

If I load the RelaxNG document from the file directory without first 
going through an xmlDoc, things work fine.

Looking at the relaxng.c code (hopefully correctly this time..), I see:

base = xmlNodeGetBase(cur->doc, cur);
URL = xmlBuildURI(href, base);

I wonder whether the right URL gets built, and, if it does, whether it 
is being resolved from the right place in the filesystem. I tried 
placing a copy of the 'foo' directory inside the 'foo' directory under 
the assumption that mistakenly resolution took place from the location 
of 'foo' instead of from the higher-up directory, but that didn't seem 
to work. I'll to find time to try debugging into libxml2 itself later today.

> One note though, I'm using dictionnaries more and more intensively those
> days, so keeping a single dictionnary for everything, while it clearly
> speed-up processing may grow quite a bit for example as you process random
> documents. It might be a good idea to "sometimes" reset the dictionnary
> to avoid explosion, for example for all the ID strings ever processed 
> by the program.

I don't use a single dictionary to speed up processing. I am using a 
single dictionary as I have absolutely no way to know which nodes from 
which nodes are going to be combined. I actually don't know what these 
dictionaries are used for (are elements stored in them? text node 
strings? both? and why? :), but having separate ones is just an 
impediment to moving nodes around freely. Moving nodes around freely is 
absolutely essential in my library's case, as the API I'm implementing 
allows this always.

What do you mean by resetting for every ID string? You mean as soon as 
an ID is encountered in an XML document? This may never happen for many 
classes of XML document, right?

Regards,

Martijn