Bug 19750 - [XQ30] Error code required
Summary: [XQ30] Error code required
Status: RESOLVED MOVED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XQuery 3.0 (show other bugs)
Version: Working drafts
Hardware: Other All
: 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: 2012-10-28 21:34 UTC by Tim Mills
Modified: 2013-05-07 16:29 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 Tim Mills 2012-10-28 21:34:28 UTC
It's possible to construct queries which pass typed data to modules with the schema-aware feature enabled.  It is an error to do this, but no error code is given.

Compare with CLT 2's XTDE1665
Comment 1 Tim Mills 2012-10-28 21:36:06 UTC
That was meant to be XSLT 2's XTDE1665.  IPad.  Fat fingers :)
Comment 2 Michael Kay 2012-10-28 21:53:22 UTC
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.
Comment 3 Tim Mills 2012-10-28 22:21:43 UTC
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".
Comment 4 Michael Kay 2012-10-29 06:03:17 UTC
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.
Comment 5 Tim Mills 2012-10-29 06:30:14 UTC
It might be worth questioning how useful it is for require/prohibit to be module and not globally scoped.
Comment 6 Jonathan Robie 2012-12-10 16:17:17 UTC
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.
Comment 7 Tim Mills 2012-12-10 16:26:13 UTC
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.
Comment 8 Jonathan Robie 2012-12-20 20:31:05 UTC
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.
Comment 9 Michael Kay 2012-12-20 23:25:26 UTC
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.
Comment 10 Jonathan Robie 2012-12-20 23:39:24 UTC
(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?
Comment 11 Tim Mills 2012-12-21 07:52:43 UTC
(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.
Comment 12 Liam R E Quin 2012-12-21 18:18:32 UTC
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.
Comment 13 Tim Mills 2012-12-22 09:20:55 UTC
(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.
Comment 14 Jonathan Robie 2013-05-07 16:29:57 UTC
Moved to Bug 20828, which introduces the Typed Data feature.