Bug 20828 - Typed Data Feature
Summary: Typed Data Feature
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-30 20:48 UTC by Jonathan Robie
Modified: 2013-05-14 16:00 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jonathan Robie 2013-01-30 20:48:27 UTC
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>
Comment 1 Michael Kay 2013-01-30 21:16:12 UTC
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.
Comment 2 Jonathan Robie 2013-01-30 21:19:36 UTC
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.
Comment 3 Michael Kay 2013-01-30 21:52:18 UTC
>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.
Comment 4 Jonathan Robie 2013-03-19 16:17:59 UTC
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.
Comment 5 Jonathan Robie 2013-03-19 18:34:32 UTC
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.)
Comment 6 Jonathan Robie 2013-05-07 16:54:07 UTC
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.
Comment 7 Jonathan Robie 2013-05-07 16:56:18 UTC
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.
Comment 8 Ghislain Fourny 2013-05-14 15:38:18 UTC
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.
Comment 9 Jonathan Robie 2013-05-14 15:58:35 UTC
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.
Comment 10 Jonathan Robie 2013-05-14 16:00:07 UTC
Ghislain noted that we need to remember the implicit typed-data-all-optional-features, per the current design of optional features.