[
Lists Home |
Date Index |
Thread Index
]
Hi Dare,
> I disagree that the distinction isn't significant. For instance in
> XQuery this means
>
> fn:data(/time);
>
> could return xdt:anyAtomicType
The data() function returns the typed value of the element. I can't
see how you get to a xdt:anyAtomicType from any of the type
definitions for the <time> element that we've been throwing around...
Based on the Data Model WD, if you have:
<time xsi:type="complexTime"><hour>14</hour><min>59</min></time>
where complexTime is a complex type with complex content, then the
typed value of the <time> element is undefined, and doing data(/time)
will give you a type error.
If you have:
<time xsi:type="simpleTime">14:59:00</time>
where simpleTime is a complex type with simple content (of type
xs:time), then the typed value of the <time> element is "derived from
its string value and type in a way that is consistent with XML Schema
validation". I've always interpreted this as meaning that the typed
value of such a <time> element would be xs:time('14:59:00'), since I
don't see anything else that would be consistent with XML Schema
validation.
If you have:
<time xsi:type="mixedTime">14:59:00</time>
where mixedTime is a complex type with mixed content (as in your
definition), then the typed value of the <time> element is
xdt:untypedAtomic('14:59:00').
> , thus
>
> fn:get-hours-from-time(/time)
>
> cannot be checked statically but instead must resort to dynamic
> failures. This is just one of many places where W3C XML Schema's
> inconsistent rules cause problems for type checking in XQuery.
I'm afraid that I'm not that hot on the whole static type checking
thing. Aren't things difficult in terms of static analysis anyway,
since one of the possible types of the <time> element is such that you
get a type error if you try to do data(/time)? If you get round that
problem, isn't it better (in terms of avoiding dynamic failures) for
data(/time) to return an atomic value of type xs:time rather than an
atomic value of type xdt:untypedAtomic, and isn't it therefore better
to have a complex type with simple content rather than a complex type
with mixed content?
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
