20828 2013-01-30 20:48:27 +0000 Typed Data Feature 2013-05-14 16:00:07 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.0 Candidate Recommendation PC Linux RESOLVED FIXED https://www.w3.org/Bugs/Public/show_bug.cgi?id=11585 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19750 https://www.w3.org/Bugs/Public/show_bug.cgi?id=19365 P2 normal --- 1 jonathan.robie jonathan.robie g mike public-qt-comments oldest_to_newest 82347 0 jonathan.robie 2013-01-30 20:48:27 +0000 In yesterday's telcon, we discussed the need for a Typed Data Feature, which can be disabled to allow a processor to be completely untyped. Here is a proposal for the feature: <proposal> 5.2.3 Typed Data Feature [Definition: The Typed Data Feature permits a data model instance to contain element nodes types other than xs:untyped and attributes node types other than xs:untypedAtomic.] If an XQuery implementation does not provide the Typed Data Feature, it MUST guarantee that the XDM has the type xs:untyped for every element node and xs:untypedAtomic for every attribute node, including nodes created by the query. </proposal> 82354 1 mike 2013-01-30 21:16:12 +0000 We need to say a little bit more than this. We need to say something about the validate expression. Either we say that a processor that does not support typed data must not support validate (that is, it must not support the schema-aware feature). Or we might allow a processor to support validate, but to do so in such a way that no type annotations are present in the result. Furthermore (and this is where the whole thing started), 3.9.1.3 §5.j says this: "If construction mode in the static context is strip, the type-name property is xs:untyped. On the other hand, if construction mode is preserve, the type-name property is xs:anyType." we should change this rule to say that if the typed data feature is not supported then the type is xs:untyped regardless of construction mode; or alternatively, to say that if the typed data feature is not supported then the construction mode must be strip. 82356 2 jonathan.robie 2013-01-30 21:19:36 +0000 Good points. I prefer: * Do not support validate * Require construction mode = strip Don't let a query claim to validate without validating, or claim to preserve without preserving. 82360 3 mike 2013-01-30 21:52:18 +0000 >Don't let a query claim to validate without validating, or claim to preserve without preserving. Well, most people would reckon that if you reject invalid documents then you are validating, regardless of what you do with valid ones; and most people would reckon that if the input is untyped and the output is untyped then you have preserved the type. So the alternatives are at least worth considering. But I don't feel strongly about it either way. 84627 4 jonathan.robie 2013-03-19 16:17:59 +0000 In today's discussion, we seemed to prefer the following approach: * In untyped mode, schema import is a static error * In untyped mode, validate is always lax * In untyped mode, construction mode = strip I will write a proposal along these lines later today. 84651 5 jonathan.robie 2013-03-19 18:34:32 +0000 Revised proposal: 5.2.3 Typed Data Feature [Definition: The Typed Data Feature permits a data model instance to contain element nodes types other than xs:untyped and attributes node types other than xs:untypedAtomic.] If an XQuery implementation does not provide the Typed Data Feature, it MUST guarantee that: 1. The XDM has the type xs:untyped for every element node and xs:untypedAtomic for every attribute node, including nodes created by the query. 2. If the query contains a schema import, an error is raised [err:XXXX]. 3. validate {} is always done in lax mode. If the query specifies strict validation, an error is raised [err:XXXX]. 4. Elements constructed by the query always have the type xs:untyped; attributes constructed by the query always have the type xs:untypedAtomic. (This is equivalent to using construction mode = strip.) 87356 6 jonathan.robie 2013-05-07 16:54:07 +0000 Revised proposal: 5.2.3 Typed Data Feature [Definition: The Typed Data Feature permits a data model instance to contain element nodes types other than xs:untyped and attributes node types other than xs:untypedAtomic.] If an XQuery implementation does not provide the Typed Data Feature, it MUST guarantee that: 1. The XDM has the type xs:untyped for every element node and xs:untypedAtomic for every attribute node, including nodes created by the query. 2. If the query contains a schema import, an error is raised [err:XXXX]. 3. Elements constructed by the query always have the type xs:untyped; attributes constructed by the query always have the type xs:untypedAtomic. (This is equivalent to using construction mode = strip.) 5. If Typed Data is not enabled, Schema Aware must not be enabled. 87357 7 jonathan.robie 2013-05-07 16:56:18 +0000 Revised proposal: 5.2.3 Typed Data Feature [Definition: The Typed Data Feature permits a data model instance to contain element nodes types other than xs:untyped and attributes node types other than xs:untypedAtomic.] If an XQuery implementation does not provide the Typed Data Feature, it MUST guarantee that: 1. The XDM has the type xs:untyped for every element node and xs:untypedAtomic for every attribute node, including nodes created by the query. 2. Elements constructed by the query always have the type xs:untyped; attributes constructed by the query always have the type xs:untypedAtomic. (This is equivalent to using construction mode = strip.) 3. If Typed Data is not enabled, Schema Aware must not be enabled. 87655 8 g 2013-05-14 15:38:18 +0000 Using the wording which is already in the spec, I would suggest to express 3. as "The Typed Data feature contains the Schema Aware feature". I think that we should (re-)assign them names (for require/prohibit-feature) such that the former name is a prefix of the latter name, so that it fits in a feature hierarchy. For example: typed-data typed-data-syntax typed-data-all-optional-features (implicit) I also think that we should provide an error code to raise in case some typed data is received from an input source or from another module, if the feature is deactivated. 87656 9 jonathan.robie 2013-05-14 15:58:35 +0000 The WG adopted the proposal in Comment #8, modified as follows: 1. The names are typed-data / typed-data-schemas 2. If a module prohibits typed data, it treats all data as untyped (no error is raised) The scope of the declaration is the module. 87657 10 jonathan.robie 2013-05-14 16:00:07 +0000 Ghislain noted that we need to remember the implicit typed-data-all-optional-features, per the current design of optional features.