RE: EntityResolver not allowed to do enough

[David N Bertoni/Cambridge/IBM]

> > > So, if the user installs a URIResolver, they must calculate
> > > the complete URL themselves or choose not to create the
> > > InputSource. That's a bit annoying but good enough for me.
>
> > Actually, the idea is you don't even have to create a URL, you
> > can just return an input source.  This works for situations
> > where the URI isn't resolved against any base URI, and let's
> > people just install a URIResolver instead of a URIResolver and
> > an EntityResolver.
>
> What I mean is that the URIResolver, if it needs the complete URI to
> generate the InputSource, must generate it itself.

OK.  Yes, that's the case.

> > It's pretty complicated, but in your example, the URI is absolute,
> > so it's never resolved against any base URI.
>
> Once again I game a bad example. Let me try again:
>
> document('http://www.w3.org/TR/xslt#document')
> => resolver->resolve(base, "http://www.w3.org/TR/xslt#document";)
>
> Inside http://www.w3.org/TR/xslt#document:
> document('foo.xml')
> => resolver->resolve(base2, "foo.xml")
>
> What is the value of base2? Is it "http://www.w3.org/TR/xslt#document";,
> "http://www.w3.org/TR/xslt";, etc?

According to the XSLT recommendation, when you call the document() function
with a single string argument, any relative URIs are resolved using the
base URI of the stylesheet.  If you want something else, you either use the
one argument form with a node-set, or the two argument form.  The
specification of the document() function is complex, so it's often
confusing.

> Having the URIResolver provide a URI is different that the Java version:
> http://xml.apache.org/xalan-j/apidocs/javax/xml/transform/URIResolver.ht
ml

> I wonder how they get around the problem of unnecessary reloads?

Good question.  I think they get a Source from the URIResolver, then ask
the Source for its systemId().  See:

   http://xml.apache.org/xalan-j/apidocs/javax/xml/transform/Source.html

How this would all work in C++ without all the run-time type introspection
of Java is still up in the air.  One way would be for the URIResolver to
return an instance of a XalanDocument.  Other choices would be for it to
act as a sort-of URL constructor, which is what I think you're thinking of.
That is, it can take two strings and determine what sort of URL can be used
to construct an InputSource that the parser can understand.  That's good
for stream sources, but not for other sorts of sources.

In all cases, we'ed need a way to get a URI that's unique for that
document.

Does this make sense to you?

> > Let's talk more about how to proceed.  I think the best way is with a
> > new URIResolver class that gets a go at the URI before we try doing
> > all the URI normalization code and using the EntityResolver.  How
> > does that sound?
>
> Sounds spiffy to me.

Excellent.  Let's start specifying it.

Dave