W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2009

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

From: <bugzilla@wiggum.w3.org>
Date: Fri, 13 Feb 2009 04:21:05 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LXpY1-0002fF-3B@wiggum.w3.org>

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





--- Comment #38 from Michael Dyck <jmdyck@ibiblio.org>  2009-02-13 04:21:04 ---
(In reply to comment #37)
> 
> constructed elements have the type annotation element(*, anyType)

This (and similar statements) misuse the term "type annotation".
You can say that an element node matches element(*,anyType) [an item type],
or that the node's type annotation is anyType [a schema type], but not that
its type annotation is element(*, anyType).

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

More correctly: The typed value of an element node with type annotation
xs:anyType is a value of type xs:untypedAtomic.

> Unforunately this results in an unsound type system, because:
> ... data on xs:anySimpleType is xs:anySimpleType.
> But XQuery 1.0 states that data on xs:anySimpleType is xs:untypedAtomic.

No, the XQuery spec makes no statement about the 'data on' judgment. It
says that if you've got a node whose type annotation is xs:anySimpleType,
its typed value (and thus, the result of applying fn:data to it) is a value
of type xs:untypedAtomic. That statement does *not* imply that 'data on
xs:anySimpleType' is xs:untypedAtomic. Rather, it implies (assuming a sound
static type system) that (roughly speaking):
    xs:untypedAtomic <: data on element(*,xs:anySimpleType)
    xs:untypedAtomic <: data on attribute(*,xs:anySimpleType)
Note that these two constraints are satisfied by the rules for 'data on' in
FS 7.2.6. Those rules have some problems, but that isn't one of them.

> 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.

That's not required for soundness, though it might well be demanded for
usability.

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

Any static typing feature will reject some valid queries. The challenge is
to not be too annoying about it.

> 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.

Although this might eliminate nodes with type annotation xs:anyType,
it doesn't eliminate expressions with static type element(*,xs:anyType).
For example, consider:

    1 + <f><e>2</e></f> / e

(which, according to the XQuery spec, also yields the value 3). Even though
the 'f' element node might be given a type annotation of xs:typed, static
analysis would still infer a static type of element(e,xs:anyType)* for the
PathExpr. If 'data on element(e,xs:anyType)' is xs:anyAtomicType*, then the
'+' would be obliged to raise XPTY0004 during static analysis.


-- 
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 Friday, 13 February 2009 04:21:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:26 UTC