[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
Hi Uche, > But I could also go with a compromise: use two different functions: > > expanded-name(node) > > expand-qname(string[, ns-context-node]) > > Actually, I like this best, now. Agreed. > I think that the added verbosity of the function call is a fine > price to pay compared to the prospect of overloading "+" to death. I > will say that even in OO languages, I've always looked on operator > overloading with much caution. Symbols, carefully chosen, can be a > powerful tool for expressivity, and they can also become a powerful > tool for confusioon. C++ iostreams is my favorite example. IMO, they > were an abomination. I and many others I know preferred to stick to > printf even though it provided a bit less formatting support. (But, > of course, not scanf ;-) ). Even better was to provide a polymorphic > pprint() method on relevant opjects that provided formatting > constructs *that made sense for that particular object*. What I'm worried about is that if we adopt the kind of proposal that you're talking about then W3C XML Schema users would have to use function calls pretty much *everywhere*. For example, they would have to do: compare-decimals($num1, $num2) = 1 or: decimal-greater-than($num1, $num2) rather than: $num1 > $num2 I can understand that you have to use functions in order to shoe-horn extended data type support into XPath 1.0, but thinking in terms of XPath 2.0 I'd like to see a natural way of making the '>' operator, for example, a shorthand for a function call. I don't think that the proponents of W3C XML Schema data types in XPath 2.0 will go for a solution that requires the user to write a function call to compare two decimals. Oh, I've just realised that I'm making the assumption that the XPath 2.0 data model would be used for this -- that values would be "labelled" with their type, such that when I pass around $num1 it is a value labelled as being an xs:decimal rather than being natively a string or a number and being converted to a particular type when a particular function has to be carried out on it. Do you think that's a bad idea? > I also don't like the fact that for some folks, RGB values will > always be far more ueful than dates. And yet they can use = for one, > and must use an entirely different syntax for another. What I'm suggesting is that in the data type definition for the RGB value, such a user could specify a comparison (returning 1, 0 or -1). Whenever the XPath processor found: $colour1 = $colour2 (where both $colour1 and $colour2 are of the type colour) it would translate that into: compare-colours($colour1, $colour2) This would enable users to use the whole range of XPath operators -- =, !=, >, <, and, or, +, -, *, div, mod -- for their user-defined data types, without being burdened with function syntax. > As you say, one has to draw the line in the sand. XPath 1.0 comes > pretty close to the right position for the line, IMO. I, like you, > have had to do date processing. However, I have never once wished > for it to be baked into the core XPath evaluation engine. Dates are, > as I said, orders of magnitude less important than > numbers/strings/booleans. > >> - the core XPath data types are compared as in XPath 1.0 >> - two data types from the same data type library are converted and >> compared as defined by that library >> - two data types from different data types libraries are both >> converted to strings and compared as in XPath 1.0 >> >> and get the best of both worlds? > > In what sense is this "the best of both worlds"? Honest question. I > think I've been insistent in articulating that mixing in the > complexity of WXS data types actually destroys the best of the XPath > 1.0 world, which is its simplicity and transparency. And the WXS > data type world has precious little for me that I would likely find > useful, so I don't see the gain. This is the best of both worlds because: 1. you only have to worry about built-in support for the XPath 1.0 data types of number, string and boolean; the code for casting, comparison and so on of the other data types are all user-defined (or available in standard data type libraries). 2. those users who want to use the W3C XML Schema data types can use them by importing a standard data type library for the W3C XML Schema data types, or by using a processor with built-in support for those data types. Once the data type library is imported, they can use those data types exactly as if XPath 2.0 supported them natively. >> I wonder whether, rather than complexifying the data-type attribute, >> the calculation could be made through an attribute value template. So >> something like (using XPath 2.0 stuff): >> >> <xsl:sort select="@num" >> data-type="{if (@num instance of xs:anySimpleType) >> then 'number' >> else type(@num)}" /> >> >> (Except that won't work because there's no way in XPath 2.0 to get the >> type of a node as a string.) > > How is it that you think what you have above is putting more > complexity into the data-type attribute than what I proposed? I'll > tweak what I proposed a bit: > > <xsl:sort select="@num" > data-type="{schema-derived-type(@num) or 'number'}" /> > > This seems a lot simpler than what you're proposing. And no new > syntax (such as instanceof) required. OK, but you've changed the semantics of 'or', which usually returns a boolean value. > BTW, instanceof is a truly bad idea in a system that has strong ties > to OO. OO is designed to avoid repeated type and capability queries, > both of which are accepted as being notorious causes of maintenance > problems in OO systems. C++ should never have introduced RTTI (they > should have started instead by fixing co-occurence). I think > isinstance is just as ill-conceived in XQuery/XPath. > > isinstance would be less of an anomaly in the model if XQuery/XPath > 2.0 were more dynamic and extensible. OK. Maybe we can come back to this then. 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
|