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,
> >> 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.
> Would you mind taking some time to expand on this a bit more? Saying
> that values are "a string with a data type as a label" is quite
> fundamental in the current design of XPath 2.0, so if there are big
> implementation problems with that, we need to address them. Plus, I'm
> interested in pursuing this "fantasy XPath" idea, and again how values
> are represented would have a major effect on whether the ideas we're
> talking about in terms of data type libraries are at all realistic.

Right now, in 4Suite, XPath strings are Python Unicode objects (which are very 
similar to Java native string objects).  There are some functions for boundary 
checking where needed, but in terms of state, the string is a native atom.

Implementing annotated strings would require that each string become an 
instance of a class, rather than a native atom.  This would cause a severe 
performance hit, and it would also require the addition of a lot of machinery 
to take advantage of the things that native atoms are already designed to make 
transparent.  For instance, one would have to come up with a hash method to 
store this XPath2 string class in a dictionary (similar to an associative 
array in some languages), which is a basic requirement of our XPath 

I suspect other implementors would have similar troubles in other languages.  
A hugely useful thing about the XPath 1.0 data types (except node set) is that 
they can be readily mapped to atomic types in most languages.  This annotated 
string idea could tend to ruin that felicity.

I also have no idea why it is needed.  If I am passing around a string, then I 
am passing around a string, and I can't imagine why I want it to be a 
Petruchio-string [*], i.e. a string one moment and a non-negative integer the 
next, according to fancy :-)

Did I ,iss a use-case?  If I want to pass around a value with a data type 
annotation, I can make it into a node and pass that about.  I then have the 
function string() to get its lexical representation, and the mooted function 
annotation() to get the fanciful bits.

[*] Petrucio from Taming of the Shrew, who observed the sun and told his bride 
Katherine that it was the moon.  After badgering her into agreeing with him 
that it was the moon, he called her a liar and pointed out how obviously it 
was the sun.

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.
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w


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

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