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

I still prefer cauution over oprator overloading, but I guess if the overload 
definition mechanism can at least be made transparent, as in the other 
suggestions,...


> 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?

From an implementor's POV, it makes dealing with variables in XPath a royal 
pain.  And Python is even more flexible in these matters than Java.  I do 
think that certainly it is an idea that should give great pause, and my 
initial reaction is quite negative.


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

I see that now.


-- 
Uche Ogbuji                                    Fourthought, Inc.
http://uche.ogbuji.net    http://4Suite.org    http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html






 

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

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