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

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 09 Feb 2009 12:15:11 +0000
To: public-qt-comments@w3.org
Message-Id: <E1LWV2d-0004Dx-Ar@wiggum.w3.org>

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





--- Comment #28 from Tim Mills <tim@cbcl.co.uk>  2009-02-09 12:15:11 ---
Thanks for looking at this report again.

I think separating out the 'typed' and 'untyped' cases is the only way to get
this (usefully) correct.  If this can't be fixed for XQuery 1.0, then the
Formal Semantics document needs to come with a prominent warning.

In our implementation, we use xs:typed as the type annotation for elements
created under the 'preserve' construction mode.  We also use it for elements
validated against xs:any with processContents="lax" when the element's type is
not defined in an imported schema.  That is, under construction mode
"preserve", newly created elements are typed as if they had been validated
against <xs:any processContents="lax">.

Perhaps parallels can be drawn with the process of validating an element
against a simple union type.  Suppose we validate against an XML Schema simple
type 'foo' defined as the union of xs:float or xs:date.  Following vaildation,
the type annotation is either xs:float or xs:date, but not 'foo'.  Similarly
when validating against xs:anyType (via xs:any), we would only ever end up with
type annotations which were subtypes of xs:anyType.

There is still a problem with stating that the typed value of an attribute with
type annotation xs:anySimpleType is xs:untypedAtomic (XQ 2.5.2 Typed Value and
String Value), since again the union of "data on" applied to the constituents
of this union type is xs:anySimpleType, not xs:untypedAtomic.  


-- 
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 Monday, 9 February 2009 12:15:21 UTC

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