RE: EntityResolver not allowed to do enough

[David N Bertoni/Cambridge/IBM]

Hi Brian,

> Is there any way to control when and how the absolute URL gets built? I
> think that this is important. I'd like to be able to provide a handler
> of this sort:
>
> string buildURI(string currentBase, string fragment)
> {
>
> }

Not right now, but that may be why Xalan-J created the notion of a
URIResolver.

> result = someobject->buildURI(base, frag)
> if (result == NULL)
>            result = XMLURL(base, frag)->getURLText()
>
> stream = entityresolver->resolveEntity(result, public)
> if (steam == NULL)
>            stream = XMLURL(result)->makeNewStream();
>
> See XSLTProcessorEnvSupportDefault::parseXML for the current
> implementation.
>
> I don't offhand know where XSL documents are loaded (i.e. for PI,
> include, import) but it should use a similar mechanism.

Again, I think the job of a URIResolver, although I don't know how this
fits in with EntityResolvers, because I don't think URIResolvers are only
responsible for string manipulation of URIs -- I think they actually do
that, _plus_ do the work of an EntityResolver.  In other words, they return
an InputSource.

> I also don't know where URISupport::getURLStringFromString fits in,
> since it seems to be doing a lot of similar work. It is also a disaster
> because it calls XMLPlatformUtils::getFullPath, which calls realpath on
> Linux. realpath will fail if the path is invalid, which will cause an
> exception and prevent the EntityResolver from getting a bite at the
> apple.

This should only happen if the URI has the file scheme or doesn't have a
scheme, in which case we assume it's a file URL.  If we're trying to do the
realpath() thing when there's a scheme present, then that's a bug.

> Can anyone explain the current architecture? It seems awfully complex to
> me....

OK, now I'm _really_ offended!  ;-)

I believe everything is supposed to funnel through
XPathEnvSupport::parseXML().  That way, the core code doesn't need to know
about how the document was created.  This should apply to parsing
stylesheets from PIs, and also for xsl:include and xsl:import.  I think
this does work, although from the perspective of the XalanTransformer
class, we don't really provide a hook to do this.

Isn't the problem really that you want to have a chance to see URIs before
they're used to parse something, so you provide an alternate source for the
byte stream?  In that case, I think you want more than just a hook to munge
strings.  Don't you want a generic hook to provide an InputSource based on
some URI or relative URI/base URI input?

It sounds like we really should add something to do URI resolution like
Xalan-J/TrAX has.  What do you think?

Dave