[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: limits of the generic


schema datatypes python
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/


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.