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.

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.

>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.

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.

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.)

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.

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.

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.

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.

Ghislain noted that we need to remember the implicit typed-data-all-optional-features, per the current design of optional features.