[
Lists Home |
Date Index |
Thread Index
]
Uche,
> It's neither baroque nor difficult for implementors either. The part
> of XPath 1.0 data typing that has the most coercion rules is the
> definition of EqualityExpression (i.e. interpretation of "=" and
> "!=".) The entire implementation of this is less than 100 lines of
> Python code, and very clear Python code, I think. In addition, about
> half of of this code is shared with the implementation of
> RelationalExpression.
>
> I would guess that the equivalent implementation in XPath 2.0 would
> run well past 1000 lines of Python code. This is just part of the
> reason why I don't plan to implement XPath 2.0. The net gain for
> such staggering complexity is frightfully minimal. Jonathan's
> examples, batting as hard as he can for data types, underscore this
> all too well.
I do agree with you that XPath 2.0's data type handling leaves much to
be desired, and that many of the data types that are supported in
XPath 2.0 (because they're built-in to W3C XML Schema) are not
particularly useful for the transformations that we've been used to.
However, I don't think that means that data types are altogether
useless. Examples that spring to mind are:
1. How to compare whether two elements have the same name. In XPath
1.0 you have to compare the local-name() and namespace-uri() to get
a namespace-aware comparison. In XPath 2.0, because the names are
QNames, you can just compare the QNames.
2. How to compare whether two date-times are the same when they use
different timezones. In XPath 1.0 this would involve some serious
work -- you'd have to bug out to XSLT for it. In XPath 2.0, because
dateTimes have their own data type, you can just compare them.
3. Similarly, how to compare whether two durations are the same.
You can derive from these examples that I consider the data typing to
be most useful for structured data types rather than for those that
could be compared as strings if the canonical lexical representation
were used.
Also, I do think that someone who's gone to the trouble of creating a
W3C XML Schema schema for their markup language is going to expect
that the data types they specified within their schema for the
elements/attributes will be used in the document, so that they won't
have to do:
<xsl:for-each select="item">
<xsl:sort select="@num" data-type="number" />
^^^^^^^^^^^^^^^^^^
...
</xsl:for-each>
if they've already specified that the 'num' attribute is an integer
within the schema. This seems the most persuasive argument for
including support for W3C XML Schema data types in XPath 2.0.
Unfortunately, the current WDs don't actually manage to support the
latter requirement -- I'm thinking particularly of the restrictions on
xs:duration -- but there's still time to change, thus increasing the
net gain from having the data types.
But it would be great if we could reduce the complexity of the
data-type support in XPath 2.0 as well. Do you have any suggestions
about which parts are the most difficult to implement and how they
might be made simpler?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
