[Bug 4273] [FS] data on element()

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4273





--- Comment #37 from Tim Mills <tim@cbcl.co.uk>  2009-02-12 10:25:36 ---
This thread is getting quite long, so it might be worth a quick summary of
where we've got to.

xs:anyType is the root of the type system

xs:anySimpleType is equivalent to xs:anyAtomicType* and is the union of all
atomic types.

element() is shorthand for element(*, xs:anyType).  All element types are a
subtype of this type.

attribute() is shorthand for attribute(*, xs:anySimpleType).  All attribute
types are a subtype of this type.

XQuery 1.0 specifies that with construction mode 'preserve':

constructed elements have the type annotation element(*, anyType)
constructed attributes have the type annotation attribute(*, xs:untypedAtomic)

and with construction mode 'strip':

a constructed element has the type annotation element(*, xs:untyped)
a constructed attribute has the type annotation attribute(*, xs:untypedAtomic)

An unknown element validated against XML Schema's xs:any with
processContents="lax" has the type annotation element(*, xs:anyType)

An unknown element validated against XML Schema's xs:any with
processContents="strip" has the type annotation element(*, xs:untyped)

Additionally, an XML Schema may declare an attribute's type to be
xs:anySimpleType, resulting in the type annotation attribute(*,
xs:anySimpleType).

fn:data can be used to return the typed value of an element or attribute.  The
type of fn:data applied to an argument is defined in XQuery Formal Semantics
using a judgement called "data on".

XQuery 1.0 states that the typed value of an element with type annotation
element(*, xs:anyType) is xs:untypedAtomic.  

Similarly, it states that the typed value of an attribute with type annotation
attribute(*, xs:anySimpleType) is also xs:untypedAtomic.

Unforunately this results in an unsound type system, because:

data on T for any particular atomic type T is T

xs:anySimpleType is the union of all atomic types

therefore:

data on xs:anySimpleType is the union of data on T for all atomic types T.

i.e. data on xs:anySimpleType is xs:anySimpleType.

But XQuery 1.0 states that data on xs:anySimpleType is xs:untypedAtomic.

data on xs:anyType is also xs:anySimpleType.  

(In fact it is the union of xs:anySimpleType and the 'error' type (relevant
when an element is a complex type containing only other elements), but this is
exactly equivalent to xs:anySimpleType.)

But XQuery 1.0 states that data on xs:anyType is xs:untypedAtomic.

It is a requirement of XQuery 1.0 that a query such as:

1 + <e>2</e>

returns 3.  This is achieved via an implicit call to fn:data on element e
returning a value of type xs:untypedAtomic, followed by type promotion to
xs:integer.  Be clear that <e>2</e> does not have type element(*, xs:integer).

If the static typing feature is to reflect the behaviour of a dynamically typed
system a query such as:

1 + <e>2</e>

must pass static typing.  If it doesn't then the static typing feature is
essentiallyl useless since it will needlessly prevent valid queries from
executing.

This can be achieved by avoiding the type annotations attribute(*,
xs:anySimpleType) and element(*, xs:anyType).  We define xs:typed

 define type xs:typed restricts xs:anyType {
    attribute * of type xs:anySimpleType,
    ( element * of type xs:anyType | text | comment | processing-instruction )*
  }

such that data on xs:typed is xs:untypedAtomic.

Instead of assigning the type annotation element(*, xs:anyType) during
construction or validation, the type annotation element(*, xs:typed) would be
assigned.

Instaed of assigning the type attribute(*, xs:anySimpleType) during
construction orvalidation, the type annotation attribute(*, xs:untypedAtomic)
would be assigned.

This leaves xs:anyType and xs:anySimpleType as abstract types.

I hope I've provided an accurate summary - I'm a little hazy  on schema
validation.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Thursday, 12 February 2009 10:25:47 UTC