[Bug 6513] [XQuery] inconsistent terminology in definition of derives-from()

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





--- Comment #10 from Michael Kay <mike@saxonica.com>  2009-03-16 18:32:55 ---
Let's suppose module M1 does "import schema namespace S1 at s1.xsd", and s1.xsd
in turn does <xs:import namespace="S2" schemaLocation="s2.xsd"/>. 

Let's suppose s1.xsd contains the definition

<xs:simpleType name="heptagon">
  <xs:restriction base="s2:polygon">
    <xs:length value="7"/>
  </xs:restriction>
</xs:simpleType>

Is M1 allowed to use the expression "$x instance of s2:polygon"?

I think our current specification doesn't give a clear answer to this question.
My preference is that the answer should be no, because that seems to be
suggested by the analogy with "import module" and <xs:import> (Though not with
<xsl:import>). However, it could go either way. Clearly if the answer is "no",
then s2:polygon is a statically known type even though it's not an in-scope
type: the processor knows about it even though the user isn't allowed to
mention it by name in that particular module.

Now suppose that M1 does "import module namespace M2 at m2.xq". The rules
discussed in the last couple of comments make it clear (a) that schema
namespaces imported into M2 are not automatically imported into M1, and (b)
that the names used in functions and variables of M2 that are referenced from
M1 must be in the ISSD of both modules. This at least creates the possibility
that the processor for module M1 statically knows about types imported into M2
even though it does not make them part of the ISSD of M1.

There may also be other types known statically to the processor. For example,
it may have a cache of types lying around from previous compilations of
unrelated queries. It may even have access to a database containing a vast
selection of all known types. The fact that these types are known does not and
should not make them available for reference in M1 - that is, the type names
are not "in scope" unless their namespace is imported.

So, the above discussion suggests three reasons why there may be types known to
the processor that are not in the ISSD.

Now, getting back to this bug, examine the text:

"An unknown schema type might be encountered, for example, if a source document
has been validated using a schema that was not imported into the static
context. In this case, an implementation is allowed (but is not required) to
provide an implementation-dependent mechanism for determining whether the
unknown schema type is derived from the expected schema type. For example, an
implementation might maintain a data dictionary containing information about
type hierarchies."

it seems on the face of it to be saying that the processor might have knowledge
about unknown types. That's pretty contradictory, until you realize that it's
using "known" to mean "types in the ISSD". If we rewrite it to say:

"The given schema type may be "in-scope" (defined in the in-scope schema
definitions), or "out-of-scope" (not defined in the in-scope schema
definitions). An out-of-scope schema type might be encountered, for example, if
a source document has been validated using schema components in a namespace
that was not imported into the static context. In this case, an implementation
is allowed (but is not required) to provide an implementation-dependent
mechanism for determining whether the not-in-scope schema type is derived from
the expected schema type. For example, an implementation might maintain a data
dictionary containing information about type hierarchies."

then it seems to me to make a lot more sense.


-- 
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 Monday, 16 March 2009 18:33:07 UTC