Hi Bob,
> Yah, C14N tends to mostly just be an application of xpath.
>
> The part that isn't part of the XPath W3C-REC is the 'document order'
> of various things. XPath doesn't define the orderings of attributes
> or namespaces, and we have to look direclty at the C14N spec to
> find that.
Ok. I studying the document this evening. Perhaps we could combine our
efforts.
It makes no sence to create different solutions for one problem ;-).
You should be the right man for this, because your xpath impl shows that you
are
an expert.
>
> Under the Normal Case, an xpath engine that enforces C14N orderings will
> be less-efficient, because in more normal uses of xpath, lexigraphical
> ordering of namespaces and attributes isn't really needed, and the
> overhead in sorting would just degrade performance.
:-(. I think that a Canonical (I hate the spelling of that word :-) )
Processor would
be faster on top of SAX. But we should implement C14N and dont do a
M$-propritary-like stuff.
By the way. James told me that you and he are working on a complete sax base
xpath processor. I already seen that project at sf but I did'nt check it out
because I
have SF-CVS access at home only. Isn't such a impl faster? Yes, of course
such
a impl is very sophisticated. I guess a SAX Canonical Impl is pleace better
on top
of that aproach. What do you think?
>
> 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.....
Toby
--
GMX - Die Kommunikationsplattform im Internet.
http://www.gmx.net
--
GMX Tipp:
Der zweitgroesste Lotto-Jackpot aller Zeiten: 36 Mio. DM suchen einen
Gewinner!
Jetzt online tippen und nebenbei noch eine Reise nach Las Vegas gewinnen!
http://www.get1.de/gmx-gewinnspiel2
"
