[
Lists Home |
Date Index |
Thread Index
]
Hi Simon,
> 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.
I understand that you don't like namespaces full stop (err, I mean
"period"), but given that we do have to live with them (and we do),
I'd much prefer people to find it easy to compare the names of two
elements or two attributes (note that my example is not about QNames
in content) by comparing their QNames than by comparing the string
representations of their names as returned by name() in XPath 1.0.
Using name() in XPath 1.0 is horrible because it isn't
namespace-aware. If we have to have namespaces (and we do), then it's
much better to treat QNames properly than to pretend that we can
compare them as strings or to force people to compare the local part
and namespace name separately.
>> 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?
Timezones don't apply to durations, but XPath 2.0 is boggled by
durations anyway, unfortunately. XPath 2.0 also seems to be treating
timezones differently from how I'd interpret their definition in W3C
XML Schema, so I guess that means it must be vague/ambiguous.
In any case, the fact that XPath 2.0 doesn't currently (in my view)
manage to treat these data types properly doesn't contradict my
statement that being able to compare date/times and durations in XPath
2.0 without bugging out to XSLT would be useful.
>> 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.
Agreed, and one of the things that *is* quite promising in XPath+XSLT
2.0 is the support for up-conversion via regular expressions. I
haven't had time to look at it in detail, but the latest XSLT 2.0 WD
has a lot on regular expression use which might prove very valuable
here:
http://www.w3.org/TR/xslt20/#regular-expressions
If you haven't looked at that already, I'm sure that the WG would be
very interested to hear your views on it as an approach.
>> 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.
Like namespaces, I'm afraid that I don't think that's a realistic
option. Given that the users have to work with what they have, I think
we should do our best to support them in doing that. For what it's
worth, I think we should support them in working with RELAX NG schemas
and future, unforeseen, validation techniques as well.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
