OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] limits of the generic

[ 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.


> 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


  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.



Jeni Tennison


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS