[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
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/
|
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
|