[
Lists Home |
Date Index |
Thread Index
]
> >> (This is not a theoretical issue. Microsoft, for
> >> one, has repeatedly used this argument to just IE's non-conformant
> >> handling of white space only text nodes.) I think some parts of the
> >> spec do only make sense if you assume the data model/input tree
> >> actually represents the XML document instead of some modified form of
>
> >> it, but stating this more clearly would be helpful.
>
> >It would be wrong. XPath should not suddenly gain a coupling to the
> >parsing
> >phase. They are distinct. Your fundamentalism exludes XPath from many
> of >the
> >places where it has been found extremely useful, including invokation
> from >DOM.
>
> Although a forced coupling seems wrong to me also, are you saying you
> believe there is something wrong with an optional coupling? I think that
> mixing Xpath analysis with the parse phase is essential to some
> applications of XML. Namely when performance is essential.
I meant XPath as a specification itself, not XPath as in the implementation
considerations of any particular implementation.
So no, there is nothing wrong for an implementation to couple XPath processing
to parsing. Many implementations already do. I also don't mind someone
introducing a spec which sets up some correspondence between, say SAX and
XPath processing analysis.
My aim in this discussion has been to encourage flexibility, not to hinder it.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/p
y.html
The Past, Present and Future of Web Services 1 - http://www.webservices.org/ind
ex.php/article/articleview/663/1/24/
The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/in
dex.php/article/articleview/679/1/24/
Serenity through markup - http://adtmag.com/article.asp?id=6807
Tip: Using generators for XML processing - http://www-106.ibm.com/developerwork
s/xml/library/x-tipgenr.html
|
