[Bug 19750] [XQ30] Error code required

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19750

--- Comment #9 from Michael Kay <mike@saxonica.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 20 December 2012 23:25:28 UTC