Re: Comments on the XPath data model, from a DOM perspective.

Hi Ray,

I am addressing only your first two comments.

In a thread in the xsl-list (in January and February) I did raise the
problem of XPath 2.0 sequences allowing heterogeneously-typed elements.
I also raised the problem why a sequence is not allowed to have
elements, which are themselves sequences. It seems that the latter
problem is just a consequence of the former problem.

Although there was understanding and positive response from some good
XSLT specialists, it seems that these problems are not going to be
solved in XPath 2.0 (as far as I'm aware).

The reply from Michael Kay was that all this can be modelled by
node-sets, but he also shared his expertise that building elements is
and will continue to be an expensive operation.

The above recommendation to use node-sets actually admits that there is
a special and very useful datatype (simulated, typed, logically correct
sequences), that is not at all described in the XPath data model.

The starting messages of the threads in which these problems were
raised and discussed are:

"The hard cocktail of sequence and (node-)set "

see in particular see:
http://sources.redhat.com/ml/xsl-list/2002-01/msg00192.html

and 

"An issue with XPath 2.0 sequences "

http://sources.redhat.com/ml/xsl-list/2002-01/msg01603.html

I think your message and this response to it should be forwarded to 
www-xpath-comments@w3.org


Cheers,
Dimitre Novatchev.



Ray Whitmer wrote:
-------------------------------

* It seems clear that the XPath 2.0 specification has no type
comparable to
the node set or other built-in types of XPath 1.0.  The concept of a 
typeless
sequence does not seem to work as effectively.  In many languages,
arrays of
objects are typed.  Although some people use untyped languages, those
who
rely on a certain level of typing are likely to complain when they lose

that,
as is being lost in this case.  There is certain distress in worrying
that
your array of matching nodes might have strings interspersed in it, and
applications which in XPath 1.0 relied on receiving sets only
containing
nodes are not going to be able to deal compatibly with a model which no
longer is able to return that type of guarantee.

* XPath 1.0 was based on explicitly unordered sets of nodes that could
be
accessed in order.  XPath 2.0 claims that every sequence is ordered,
but
there is not sufficient discussion of what that means, which has caused
significant confusion.  The logical conclusion could be drawn that it
is
referring to document order, which is the only order it seems to define
and was the order of XPath 1.0, but this makes no sense when
considering
non-node items now possible in the result sets.  Also, the incompatible
treatment of duplicates is confusing, if the sets are now ordered,
rather
than unordered, it seems pointless to not eliminate the duplicates, but
there is probably something lost between the different versions of the
specification.

Based upon recent discussions, it seems that the XPath 2.0
specification
may not be comparable or compatible with the XPath 1.0 specification in
its
use of these terms, but the specification needs better treatment of the
concepts, and explanation of the impact on backwards compatibility.
Elimination of duplicates also seems like a significant compatibility
problem since 1.0 implementations went to great lengths to accomplish
this.



__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/

Received on Friday, 5 April 2002 09:16:54 UTC