- From: <bugzilla@jessica.w3.org>
- Date: Thu, 03 Jun 2010 09:38:13 +0000
- To: public-qt-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9327 Oliver Hallam <oliver@cbcl.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oliver@cbcl.co.uk --- Comment #2 from Oliver Hallam <oliver@cbcl.co.uk> 2010-06-03 09:38:12 --- I disagree that a static typing implementation must raise an FOTY0012 error. In 4273 comment #49, Michael Dyck lays out several possible solutions to the problem that were considered. Whilst the working group settled with solution 1, it is permitted for an implementation to extend the static typing rules, and implement solution 2. In this case an implementation could notice that there are no types derived from the type of mc:letter and thus this error need not be raised (it could at this point infer that the static type is xs:untypedAtomic). Thus I believe that it should allow no error to be raised, even in static typing modes. In order to make this test watertight the schema needs to contain * a complex type, mc:mixed, with mixed content * a complex type, mc:elementOnly, restricting mc:mixed with element only content. The node cannot be directly constructed in the query, as then static analysis can identify the schema type of the node exactly. Thus the node must be passed in from the external context. I believe that with the proposed schema modifications the following test would behave appropriately: import schema namespace mc ="http://www.w3.org/XQueryTest/mixedcontent"; declare variable $node as element(*, mc:mixed) external; data($node) where $node is a document containing an element with type mc:mixed. This test would then always require FOTY0012 in static typing mode, but would return a result in dynamic typing mode. -- 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, 3 June 2010 09:38:14 UTC