[
Lists Home |
Date Index |
Thread Index
]
Amy et al.,
This discussion on pluggable type libraries is very interesting and
it's comforting to see that it fits in with the discussions some of us
had about types in XPath NG a while ago.
Just some random thoughts:
I agree with Dare that thinking about how to define the processing of
values of these pluggable types as well as their validation is really
important. In particular, that means supporting casting rules and
arithmetic operators as well as comparisons between values.
John brought up the issue of types that don't have total ordering. The
lack of total ordering of durations and date/times with or without
timezones has been a real pain in XPath 2.0 because for optimisation
purposes you really need just one of $a = $b or $a != $b to be true.
You could, of course, introduce three-valued logic to cope with the
ambiguity, but I'd be interested if anyone had any other bright ideas.
Another area that I think would benefit from some consideration is the
handling of compound types such as date/times (made up of year, month,
day, hour, minute, second, timezone), durations (made up of years,
months, days, hours, minutes, seconds) and QNames (made up of a local
name and a namespace URI, plus a prefix depending on how you define
it). These compound types are the cause of the proliferation of
functions in XPath 2.0 like get-year-from-dateTime() and
get-local-name-from-QName(). If we had a standard way of defining the
components of a particular type, we could have a standard way of
accessing them (such as an extract() function or a . operator).
Finally, I think that there should be limits on the scope of a type
definition. XML types like ID and ENTITY have too wide a scope, in my
opinion, in that they specify constraints across entire documents as
well as on particular lexical representations. A good rule would be
that all you should need to tell whether a value is a legal value is
the lexical representation itself, but unfortunately QNames wouldn't
be allowed if that were the rule. Perhaps limiting the information
available to the lexical representation plus XML-defined context
information -- namely namespaces, the base URI, language and
whitespace preservation -- would be better?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
