[
Lists Home |
Date Index |
Thread Index
]
Jonathan Robie wrote:
>>Are we talking about the XPath built-in types or the W3C XSD
>>"primitive" types? My sense of the 80/20 point for typing is
>>strings, date-time, integers, floating points ... maybe 1-2 more.
>>The 30 or so "primitive" types that make controversial distinctions
>>between short and long integers, dates and times, etc. etc. do not
>>seem like a sensible starting point for a minimial conformance
>>level.
>
> I can understand the desire for fewer types. But if you support any
> data types in documents, its hard to justify not supporting those
> data types found in the documents that are being queried, which may
> belong to any built-in type.
Yes, I'm not sure that you can draw the line at the primitive data
types, in particular because that means you can't distinguish xs:ID or
xs:integer, which seem to play a fairly major role in XPath/XQuery.
(Although I don't see any particular reason why they should
particularly -- XPath 1.0 managed OK with the equivalent of xs:double,
and as I've argued previously, xs:ID isn't as useful as you might
think.)
>>What about the functions and operators? That seems at first glance
>>like something that could be pared down significantly for a minimal
>>implementation. I guess a lot of them would be irrelevant if only
>>the built in types are supported....
>
> You got that right. Or if we had a general framework for data
> accessors that did not require a new function every time you want to
> get one field out of a simple type like a date.
I think that's certainly worth considering. I was toying with the idea
of "virtual elements" of some kind, so that a date could be
manipulated as if it were in the format:
<year>2002</year>-<month>05</month>-<day>13</day>
such that if you had:
<date xsi:type="xs:date">2002-05-13</date>
you could get the year of the date using:
data(date)/year
I suspect that's overloading the / operator, however. Perhaps just a
"of" operator would be useful:
year of date (QName "of" Expr)
being the equivalent of the current:
get-year-from-date(date)
I think that the question to be answered here is whether XPath 2.0
should support external objects. If the answer is "no", then I don't
think it should be too much of a burden to list (or supply general
rules for) the functions that extract specific data from atomic values
of the 19 primitive types -- at least it is a finite list. If, on the
other hand, XPath 2.0 is going to support external objects, then a
general mechanism for accessing the properties, and possibly methods,
of those objects would be useful.
I am vaguely in favour of supporting external objects, since it gives
the room for extension and customisation that I think is important in
a core technology like XPath. If, for example, XQuery decided that it
wanted to pass around "type definition" objects, then these could be
treated like other external objects within XPath. Similarly, if a
future version of XSLT wanted to extend XPath to support functions as
objects, then it could do so.
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
