List --
A few months back, I talk with James Strachan about enhancing Jaxen so that
invocations of the document() function would use custom URI resolvers.
I reached the point of scoping out the required changes, and I'd like to solicit
feedback before making and committing the changes. Here's a list of what might be
done:
The document function currently invokes the getDocument() method on the relevant
Navigator; getDocument() accepts a URI and returns an Object. The current
implementations are:
* DOM: create new DocumentBuilderFactory, create new DocumentBuilder, call parse on
String URI.
* DOM4J: invoke the read() method on a SAXReader
* Electric XML: pass a File to the Document() constructor
* JDOM: pass String URI to the build() method on a SAXBuilder.
In the cases of DOM, JDOM, and DOM4J, the relevant methods all accept
org.xml.sax.InputSource, so a switch to using an EntityResolver is straightforward in
each case. For Electric XML, the InputStream or Reader will have to be unbundled from
the InputSource, but is a dependency of Jaxen on SAX a desirable thing? EXML doesn't
include SAX, but use of InputSource would require this. (I would say that SAX
dependency is not a bad thing.)
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.)
So, any input from the primary architects?
-- Paul
-------------------------------------------------------
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone? Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
_______________________________________________
Jaxen-interest mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jaxen-interest
