[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|