- From: Philippe Le Hegaret <plh@w3.org>
- Date: 15 Feb 2002 15:05:50 -0500
- To: Karl Scheibelhofer <Karl.Scheibelhofer@iaik.at>
- Cc: "'Christian Geuer-Pollmann'" <geuer-pollmann@nue.et-inf.uni-siegen.de>, w3c-ietf-xmldsig@w3.org
On Fri, 2002-02-15 at 02:53, Karl Scheibelhofer wrote: > i just read some of the XPath sections again. i cannot figure out how > the behavior of Xalan can be compliant with the XPath 1.0 recommendation > (i really do not care about any working draft for a future version). > maybe it is compliant with the mentioned working draft, but i guess it > is not compliant to XPath 1.0. Well, you're trying to deal with 2 different data models at the same time which is an unsolvable problem. The data model used by the DOM API is not the same as the one used by the XPath API, so you can't really expect a DOM result to be fully compliant to XPath 1.0. > perhaps, it is very hard or not possible to be compliant with XPath 1.0, > if you are working with DOM as it comes out of a parser. > however, this situation is really unsatisfying for me. Note that the DOM Level 3 Load and Save module [1] is introducing a feature called "load-as-infoset" when building a document in memory. CDATA sections nodes will not show up in the DOM tree if you use it, and Text nodes will be normalize (i.e. only one Text node per text content). One of the advantages is that you obtain a DOM tree fully compliant with the XPath 1.0 data model. In this case, the Xalan result will be exactly what you expect it to be. So, I don't know if xerces as a "load-as-infoset" feature on its load function, but if it does, I suggest you use it when doing XPath queries in the DOM tree. Philippe [1] http://www.w3.org/TR/2002/WD-DOM-Level-3-ASLS-20020114/load-save.html#LS-Interfaces-DOMBuilder
Received on Friday, 15 February 2002 15:05:59 UTC