[
Lists Home |
Date Index |
Thread Index
]
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/
|
