[
Lists Home |
Date Index |
Thread Index
]
Dear Jeni,
On Wed, 14 May 2003 10:41:55 +0100
Jeni Tennison <jeni@jenitennison.com> wrote:
(thoughtfully as usual)
> 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.
I'm not at all so certain. I think the treatment of type manipulation,
rather than of type validation, is key to the problems with W3C XML
Schema. At the least, I think that it ought to be possible to validate
without concern for the "next level" (the path, query, and transform
languages).
Casting has to be handled carefully, especially in a pluggable context.
If it is defined as type -> type, then it's unworkable. If it's defined
as string (ur-type) -> type, then it might work. Basically, this would
require definition of how a type is instantiated from the lexical form
(only). The problem to avoid, of course, is combinatorial explosion.
> 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.
Some. For dates, the concept of "contains" helps, and could apply to
other types in which less precision creates larger spans. Using the W3C
XML Schema types, "overlaps" is probably more accurate, though, and I
don't know how useful that is.
> 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).
That, actually, I think can be solved, with better compositors and rules
for composition. Then a compound simple type can be composed of atoms,
which can be named, and presumably a transform/query language could be
extract by name.
I'd give an example, using ISO 8601 dates, but I'm in a bit of a hurry,
so maybe later. Particularly as there are still biggish chunks to work
out. Allowing composed primitive types, though, is likely to help a
bunch of folks who have relatively specialized needs.
> 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
Good point.
> 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?
Hmm. But why, then, can't uniqueness also be specified?
It's an interesting problem. I'm not sure that ID or key is a "type" in
the same way that, for instance, "number" or "boolean" is a type, or
even as "qname" is a type. But is forbidding use of "unique within a
scope" a solution, or just dodging the problem?
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
Love doesn't just sit there, like a stone, it has to made, like bread,
remade all the time, made new.
-- Ursula K. Le Guin
|
