This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Fwd: Re: Comments on the XPath data model, from a DOM perspective.
- From: Dimitre Novatchev <dnovatchev at yahoo dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Thu, 4 Apr 2002 07:52:01 -0800 (PST)
- Subject: [xsl] Fwd: Re: Comments on the XPath data model, from a DOM perspective.
- Reply-to: xsl-list at lists dot mulberrytech dot com
--- Dimitre Novatchev <dnovatchev@yahoo.com> wrote:
> Date: Thu, 4 Apr 2002 07:48:36 -0800 (PST)
> From: Dimitre Novatchev <dnovatchev@yahoo.com>
> Subject: Re: Comments on the XPath data model, from a DOM
> perspective.
> To: www-xml-query-comments@w3.org, Ray Whitmer <rayw@netscape.com>
> CC: Michael.Kay@softwareag.com
>
> 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/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list