[Bug 5738] [XQuery] Constraints on schemas

http://www.w3.org/Bugs/Public/show_bug.cgi?id=5738





--- Comment #4 from Michael Kay <mike@saxonica.com>  2008-07-29 18:00:09 ---
In discussion, there were clearly a number of people who felt that the term
ISSD was intended to mean what I meant by "static schema", that is, all the
schema definitions available to the processor during static analysis.

I think there are a couple of difficulties with this. Firstly, it means that
"import schema" loses any connection with the <xsd:import> element on which it
was originally based; it can no longer be described as giving the query access
to a particular set of component names in a particular namespace. If we want to
do this we should probably say explicitly that "import schema" IS transitive,
that is, it imports all the schema components in and referenced by the
identified schema document, irrespective of their namespace, so that the user
has some kind of predictability in knowing which names can be used in a query
as a consequence of a given "import schema" declaration.

This incidentally would make "import schema" very different from "import
module", which is explicitly NOT transitive.

(The current spec of "import schema" is very muddled, and it's not surprising,
because the schema composition story in XSD itself is so muddled. We talk about
a schema "being identified by its target namespace": but schemas don't have
target namespaces, only schema documents (and schema components) do. XSD itself
has the notion of "the schema corresponding to a schema document" - we could
use that term, though unfortunately it is itself pretty weakly-defined.)

Secondly, I think that it we adopt this wider interpretation of ISSD, then the
contents of the ISSD become very variable from one implementation to another,
which means that many queries are going to fall foul of rules like this one:

<rule>
It is a static error [err:XQST0036] to import a module if the importing
module's in-scope schema types do not include definitions for the schema type
names that appear in the declarations of variables and functions (whether in an
argument type or return type) that are present in the imported module and are
referenced in the importing module.
</rule>

when queries are moved from one implementation to another. Now it's true enough
that we already say the ISSD is "augmentable", but my interpretation of that
has always been that as an alternative to importing a schema namespace in the
prolog, you can do it from the API. An interpretation that puts the contents of
the ISSD largely in the hands of the implementation rather than the user is
going to cause a lot of interoperability problems.

I think it's actually useful to make a distinction between "the set of types
that the schema processor knows about at analysis time" and "the set of types
that the query is allowed to mention by name". It means that when you read the
"import schema" declarations in the prolog, you know something about the
module's dependencies, just as you do if you read the "import module"
declarations.

Finally: the consistency constraints that are the subject of the original bug
clearly apply only in the case of a processor that is doing static type
inferencing. 


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 29 July 2008 18:00:44 UTC