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