[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

[xsl] Fwd: Re: Comments on the XPath data model, from a DOM perspective.


Subject: [xsl] Fwd: Re: Comments on the XPath data model, from a DOM perspective.
From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
Date: Thu, 4 Apr 2002 07:52:01 -0800 (PST)

--- Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote:
> Date: Thu, 4 Apr 2002 07:48:36 -0800 (PST)
> From: Dimitre Novatchev <dnovatchev@xxxxxxxxx>
> Subject: Re: Comments on the XPath data model, from a DOM
> perspective.
> To: www-xml-query-comments@xxxxxx, Ray Whitmer <rayw@xxxxxxxxxxxx>
> CC: Michael.Kay@xxxxxxxxxxxxxx
> 
> 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@xxxxxx
> 
> 
> 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/

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list



Current Thread
Keywords