Paul Brown wrote: <snip/> > The same question arises in the context of using an EntityResolver, i.e., EXML >doesn't presuppose the presence of SAX classes. (In this case, Jaxen would also need >to supply a default entity resolution behavior, i.e., use of java.net.URL.)
I hope no one minds my tossing in 2 cents, here. I don't think the SAX EntityResolver is the right interface to use. Quite apart from the issue of introducing a SAX dependency, I think it is a poor fit. For one, the EntityResolver receives a public ID and a system ID. There is an extra parameter, there, that will never be used by the document function. More importantly, though, EntityResolvers are supposed to always received an absolute URI for the system ID. The document function is supposed to be able to accept a relative URI and resolve it to an absolute URI based on the base URI in effect (or the base URI of the node passed as the second argument, which Jaxen's document function does not currently support). I think if some entity resolution is added as a standard feature, it should try to address the requirement of being able to resolve relative URIs based on the context. That would be a good feature. Perhaps even add a getBaseURI method to Navigator. Looking for an xml:base attribute in scope could be done in a generic fashion, but adding this to Navigator could permit optimizations by particular implementations, or permit implementations that can know the system ID of the document in the absence of an xml:base attribute to still provide a meaningful answer. This came up as an issue for some stuff I'm working on. I solved it by creating an adapter class that implements the Navigator interface and acts as a proxy for the real Navigator. All of the methods except the getDocument method just call through to the target navigator; the getDocument function resolves absolute URIs using a base URI provided during instantiation, then passes the absolute URI on to the target Navigator. I create a fresh one for each XPath expression that needs a unique base URI. An alternative solution that lets me associate a resolver with each Context would be fine with me, but I don't see EntityResolver as a good fit for this. ------------------------------------------------------- This SF.NET email is sponsored by: AMD - Your access to the experts on Hammer Technology! Open Source & Linux Developers, register now for the AMD Developer Symposium. Code: EX8664 http://www.developwithamd.com/developerlab _______________________________________________ Jaxen-interest mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jaxen-interest