> There was a patch from a user to let the installed EntityResolver have
> a go at any URLs given to the document() function. I applied this
patch,
> but I'm not sure if the provider ever verified it.
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)
{
}
pseudocode:
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.
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.
Can anyone explain the current architecture? It seems awfully complex to
me....
> Brian, can you provide a minimal set of input files (stylesheet,
source
> documents, source code) that illustrates the problem? That way, I can
> take a look at it and see what's going on.
I can't easily provide you with a usable example because these problems
are being demonstrated through my Xalan-C Python bindings.
I can write a C++ example, if that would be useful, but not immediately.
Cheers,
Brian
