[
Lists Home |
Date Index |
Thread Index
]
Jeni Tennison describes as not "altogether useless":
> 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.
Given the remarkable nastiness of QNames, as structured datatypes whose
"real" value changes based on context, I'm not sure I can consider
anything involving QNames to be a feature. XSLT's provision of global
context has kept them from making XPath too crazy, but I can't say use
of QNames is a practice I'd encourage.
> 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.
I thought both of these were boggled by the vague status of timezones in
W3C XML Schema. Has that changed?
> 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.
There are lot of other possibilities for conversion from lexical
representation to structure that offer far more flexibility than the
current system of predefined types. Regular fragmentations is one
possibility, though I think Eric van der Vlist's xvif goes much further
in making this kind of processing useful in a broader development
framework.
> 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.
It seems like this is a good opportunity to tell those folks that
they've been grossly misled by the purveyors of W3C XML Schema bogosity
rather than driving the same set of mistakes ever deeper into the tool
set.
> 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?
>From my perspective, tossing W3C XML Schema's odd collection of types
and facets from XPath in favor of smaller pieces of more configurable
processing that takes place before XPath itself approaches the data
would greatly simplify the implementation.
But I guess XPath 1.0 is already largely capable of handling that work,
so it shouldn't do much harm for XPath 2.0 to continue its seemingly
exponential growth.
-------------
Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid:1.3.6.1.4.1.6320 is another possibility altogether
|
