> > 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.
> 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?
> If we implement URIResolver, there's no need for the URIResolver
> instance to maintain anything. The only rule is that it must behave
> deterministically during a particular transformation (so we don't
> parse the document a second time). That's why the URIResolver has
> to provide a "URI" that we can use as a key for the document.
> You can think of URIResolver as EntityResolver + "thing that can deal
> with custom URI schemes, etc." Does that make sense?
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?
> 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.
Cheers,
Brian
