- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 09 Feb 2009 12:15:11 +0000
- To: public-qt-comments@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