Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
 Uche, >> 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. > > This has nothing to do with data typing, IMO. The idea of expanded > name equivalence predates WXS, and is already omnipresent in XPath > 1.0 (i.e. name tests in the form of qnames). The fact tthat this > cannot be done in EqualityExpressions is an oversight that can be > corrected without dragging in all of WXS data types. Just add a > function expanded-name() (abbreviate it, perhaps), that takes an > optional QName or a node set. If it's given a QName, that's what it > expands. If it's given a node set, it uses the expanded ame of the > first docorder item of that node set. If used without an argument, > "." is assumed. Then you can simply do: > > expanded-name() = ns:foo > > in your expressions, and the problem is solved. no? Sorry, I don't follow. What does the expanded-name() function return? A node set of two text nodes (or a sequence of two strings in XPath 2.0 parlance)? Or an element that's structured in a certain way? > Actually, I'd say such an exsl:expanded-name() would be a handy > addition to the EXSLT core module. Great. I'm all for adding things to EXSLT if they'll help XPath 1.0 users get the good functionality from XPath 2.0 without the bad overhead. >> 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. > > EXSLT date-times module provides for this without needing to infect > the core. Yes, but as you know there are implementations that don't support the EXSLT date-times module. Also, I think that users will find it difficult to understand why they can do 1 + 1 but can't do 2002-09-28 + P1Y. Native support for date-time values and durations is one of the main things that's missing from XPath 1.0, in my opinion. Extensions can plug the gap temporarily, but if we want all users to benefit it has to be in the core. >> 3. Similarly, how to compare whether two durations are the same. > > I think the subsequent discussion of this one closes the case ;-) Well, I don't agree. Just because a solution to something is contentious or hard to define doesn't mean that it isn't a requirement. >> 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. > > And I see all the cases you mention better handled by explicit > checks rather than built-in coercion rules. Sorry, I don't follow (it must be late). What do you mean by an explicit check? Something done with a function call rather than an operator? Or...? >> 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> > > But there is a middle ground. Just one possible way to spell it: > > <xsl:for-each select="item"> > <xsl:sort select="@num" data-type="schema-derived()" /> > ... > </xsl:for-each> > > Which has the nice advantage that the user can also do: > > <xsl:for-each select="item"> > <xsl:sort select="@num" data-type="schema-derived() or 'number'" /> > ... > </xsl:for-each> > > Menaing "use the schema-derived type if available, and fall back to > number if it isn't". I agree something like that would be a very good middle way. > Can't you see how blindly relying on the schema type makes an ugly > dependency between the XSLT and the instance document? By handling > it declarative, as I suggest, the above example is *much* safer for > modularization and reuse. This is the advantage of generic > approaches. Oh, absolutely I can see that. I don't think that it's good practice to rely on a schema to provide you with typing information about an instance, any more than it's good practice to rely on a DTD to provide you with default attributes. But that does not mean that other users won't want to work in a schema-aware way. In the same way as I don't think that those users should inflict their prejudices and preferences on us (and I'm aggrieved that they are), I don't think we should inflict our prejudices and preferences on them (despite the fact that we're obviously right ;) >> 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. > > Doesn't persuade me one bit. Doesn't surprise me one bit :) >> 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? > > This seems obvious to me. The fact that I have to support all the > comparison rules for all the WXS data types in order to implement > EqualityExpr is more than enough to bloat the Python function 10x. > They can be simpler by not being there at all. Why do I have to > support one committee's arbitrary motley of data types that may have > nothing to do with any conceivable needs of my users? > > At least using generic approaches, I can plug in the details in a > modular fashion, as they are called for. I wondered whether it might be the casting that was the problem, since that seems one of the more complex areas to me. In terms of dealing with testing equality between the extra data types, perhaps you can simplify the code by creating the canonical lexical representation for each value and comparing them as strings? (I know that doesn't work for some data types where the canonical lexical representation isn't yet defined.) 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
|
|||||||||
