> It makes no sence to create different solutions for one problem ;-).
Definitely. Am already planning for the xpath impl to support
everything needed by a C14N impl.
> By the way. James told me that you and he are working on a complete sax base
> xpath processor.
Just for clarification, is SAX-esque, not a SAX-basd xpath processor.
It's for parsing stringified xpath expressions into an event/callback
model similar to the SAX API, but pretty much unreleated to SAX.
Due to re-orderings/replacements of things in the XML stream, I don't
we can do a straight c14n filter on top of the SAX events. I think,
like XSLT, for the most part you need a fairly complete object-model.
> > Rearrangement of namespaces also fall outside the scope of the xpath
> > spec.
>
> Ok. But that is then a dom4j related implementation placed higher than your
> XPath
> application from the view of Canonical Facade class.....
Yah, I figure actually a C14N engine could eat a dom4j Document,
process it through the XPath engine, do some sorts and replacements,
and return the canonical dom4j Document.
-bob
_______________________________________________
dom4j-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dom4j-dev
