[
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
implementation.
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.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
