W3C home > Mailing lists > Public > public-qt-comments@w3.org > January 2011

[Bug 11710] New: Rules for derives-from() when the dynamic type is not known statically

From: <bugzilla@jessica.w3.org>
Date: Sun, 09 Jan 2011 22:31:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-11710-523@http.www.w3.org/Bugs/Public/>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11710

           Summary: Rules for derives-from() when the dynamic type is not
                    known statically
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: jonathan.robie@redhat.com
        ReportedBy: mike@saxonica.com
         QAContact: public-qt-comments@w3.org


This is a follow-on to bug #10291 against test case module-schema-context.

The essence of the test is that a function F in module M1 returns a value of
type my:int which is a subtype of xs:int; the caller in module M2 tests "F()
instance of xs:int", when my:int is not imported into M2.

The originator of the bug considered that a valid result for this test was
XPTY0004; the WG decided (it appears) that such a result would be unacceptable
from a usability and interoperability perspective, and that the spec therefore
needed to be "clarified".

There has been some attempt to clarify the rules here in the 3.0 spec, but they
still leave this case implementation-defined.

Firstly, the sentence "Some of the rules for SequenceType matching require
determining whether a given schema type encountered as a type annotation in an
instance document is the same as or derived from an expected schema type."
needs to be generalized so that it also covers type annotations on atomic
values (which as in this example can be produced by casting, not only by
validation).

Secondly, the rule

2. potentially, the schema used for validating the instance document; whether a
processor adds this schema to S is implementation-defined.

allows a processor to return XPTY0004 for this test query, and it appears that
we want to disallow that. To achieve this, I believe we should change the rules
to:

<new>
Some of the rules for SequenceType matching require determining whether a given
schema type T encountered as the dynamic type of an XDM value is the same as or
derived from an expected schema type. This determination is done by reference
to a schema S (that is, a set of schema components). This schema S is the union
of:

1. the in-scope schema definitions in the static context of the module.

2. the type definition T

3. the base type of every type that is present in S

4. potentially, further schema components that have been made available to the
processor in an implementation-defined way.

</new>

and then delete the paragraph starting "Whether the schema..."

If we want to disallow an XQuery 1.0 processor from returning XPTY0004 for this
query then we also need a corresponding erratum to XQuery 1.0.

-- 
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 Sunday, 9 January 2011 22:32:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:45 UTC