That was meant to be XSLT 2's XTDE1665.  IPad.  Fat fingers :)

Makes me wonder whether it is legitimate for a product to require that either all modules participating in a query are schema-aware or all modules are not schema-aware.

Indeed, but I suppose you'd still have to catch possible typed data from fn:doc, or external variables.  It's certainly quite a bit of overhead to perform the checks.

Of course, I should have said "with the schema aware feature disabled".

The run-time checks are fairly straightforward, it's the constraints on inlining functions and variables from a different module that give me the jitters.

It might be worth questioning how useful it is for require/prohibit to be module and not globally scoped.

I believe we addressed this in Lyon. If a module or implementation is not schema-aware, it need not strip typed data.

See the current text for the Schema-Aware feature.

I don't quite understand your response.

Are you saying that it is not an error to pass typed data from a schema aware module to a non-schema aware module?

It was not my intention to suggest that passing such data would result in the type information being stripped - only that the situation would be detected and treated as an error.

It is not an error to pass typed data from a schema aware module to a non-schema aware module.

The Working Group confirmed that in today's call.

That seems incompatible with the decision reached on bug #11585. It seems fairly clear from the discussions in recent telcons that the problem of mixing schema-aware and non-schema-aware modules is one that we don't yet fully understand or have an answer for. Several people took a lively part in the discussion last week, many of them appealing to the concrete behaviour of their own implementations, which appear to be very different from each other; this is clearly something that needs more work.

I think we can assume:

(a) we are interested in solving the problem in a way that allows modules to be separately compiled

(b) we don't expect modules compiled under one processor to interoperate with modules compiled under a different processor (unless they come from the same vendor, ie are variants of the same processor)

(c) some processors will be schema-aware, others won't

(d) it's desirable that stylesheet authors should be able to write a library module that requires schema-awareness, or that requires schema-non-awareness, to ensure that the module has conistent behaviour across implementations

(e) it's desirable that a library module that requires schema-non-awareness should be callable from a module that is schema-aware.

One possible approach to this is that the author of the non-schema-aware library module should explicitly state the expectation that incoming data will be untyped in the public function signatures, for example by declaring a parameter as "$emp as element(employee, xs:untyped)". This then puts the burden on a schema-aware caller to create an untyped version of the data to be passed across. (Note: XSLT has facilities to create an untyped copy of typed data; in XQuery, there's no easy way of doing this.)

Another possible approach is to treat this requirement as implicit: if a module is explicitly non-schema-aware, then the functoin signatures are treated *as if* they required xs:untyped elements and xs:untypedAtomic attributes.

Both these approaches have the effect that passing typed data to an untyped library module is an error. 

Another approach is to say that the untyped copy of the data is created automatically as a result of the function calling mechanism. This would be problematic, however, because it loses node identity.

Another approach is to say that the data passed across the interface retains its type annotations, but the untyped module ignores them. The detail of this creates many complications. Having two modules give different answers to basic expressions like "$price gt 5" seems very unappealing.

Jonathan in comments 6 and 8 seems to be suggesting that we resolve this by essentially making it impossible to write a module that has the guarantee "all data seen by this module is untyped" (unless it explicitly forces this by littering the code with "as xs:untyped" declarations everywhere). This suggestion  doesn't seem to meet one of the requirements stated above, which is that the library module has consistent behaviour regardless whether the caller is schema-aware or not. It also ignores the performance argument, which is that code which knows at compile time whether it is handling typed or untyped data can be far more efficient than code that doesn't know this until run-time.

I'm coming to the conclusion, though, that this is probably the best we can do. The consequence is that it's not possible, in any meaningful sense, for a library module to be "non-schema-aware" if the implementation allows it to be called from a schema-aware module; a module that can be called from a schema-aware module has to be prepared to deal with typed data. My conclusion is that we should remove the facilities which currently purport to make schema-awareness a property of a module, rather than a property of the query as a whole - these facilities simply don't work.

(In reply to comment #9)

We do make decisions in later meetings that are different from decisions we made at earlier meetings.

I think you and Tim are asking for a feature that we do not currently provide. I do not believe that this is a bug or a requirement for XQuery 3.0. Perhaps we should explore this in XQuery 3.1?

(In reply to comment #10)
> (In reply to comment #9)
> 
> We do make decisions in later meetings that are different from decisions we
> made at earlier meetings.
> 
> I think you and Tim are asking for a feature that we do not currently
> provide. I do not believe that this is a bug or a requirement for XQuery
> 3.0. Perhaps we should explore this in XQuery 3.1?

I reluctantly think this is a feature request, but observe that marking a module as prohibiting the schema aware feature is a pointless activity, merely resulting in one error code being substituted for another (in the case that the processor is not schema aware).  In the case that the processor is schema aware, it seems far fetched that a developer would bother to write a prohibition statement after having written an import schema declaration!

Marking modules as prohibiting the module import feature appear equally pointless.

Personally I'd remove the prohibit/require feature from the spec until it does something more useful.  Its lamentable location in the grammar, following many of the syntactic features which it affects, doesn't help.  Being able to switch on or off static typing is quite useful, but that is about it.

An example of wanting to prohibit module import might be where you're constructing a module on the fly from multiple sources; this seems not uncommon in web app backends.

(In reply to comment #12)
> An example of wanting to prohibit module import might be where you're
> constructing a module on the fly from multiple sources; this seems not
> uncommon in web app backends.

I'd hazard a guess that it would be easier to identify module import statements in the sources (and raise an error) than to get the prohibition declaration in the right place when constructing the module to let XQuery do the work.

Moved to Bug 20828, which introduces the Typed Data feature.