W3C home > Mailing lists > Public > public-qt-comments@w3.org > October 2009

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

From: <bugzilla@wiggum.w3.org>
Date: Tue, 06 Oct 2009 21:21:13 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MvHT7-0006My-MJ@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6513


Jonathan Robie <jonathan.robie@redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #21 from Jonathan Robie <jonathan.robie@redhat.com>  2009-10-06 21:21:13 ---
The Working Group adopted a modified form of this in today's telcon. I'll mark
the modifications inline.

(In reply to comment #18)
> I believe a better approach to solving this problem would be along the
> following lines:
> 
> <new>
> 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. 
> 
> 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 query module
> 
> (2) the schema used for validating the instance document.

Whether or not (2) is included in S is implementation-defined.

> (3) potentially, further schema components that have been made available to the
> processor in an implementation-dependent way.

(3) is also implementation-defined (not implementation-dependent).

> A type error [err:XPTY0004] *may* [or *must*?] be raised if this union does not
> constitute a valid schema (for example, if there are conflicts between types
> present in the static context and types used dynamically for validating
> instances.)
> </new>

This is MAY.

> We can then reduce the definition of derives-from to:
> 
> <new>
> # derives-from(AT, ET) raises a type error [err:XPTY0004] if either AT or ET is
> not present in S
> # derives-from(AT, ET) returns true AT and ET are both present in S, and if one
> or more of the following three conditions is true:
> 
>    1. AT is the same type as ET 
>    2. AT is derived by restriction or extension from ET

We discussed whether "or extension" should be implementation-defined or
required of all implementations, and opinion was more or less evenly divided. 

Some argued that implementations need the freedom to use dynamic schemas, but
also need the freedom to optimize. Some argued that this is too confusing for
the user, and that an implementation should either use the schemas from (2) and
(3) or not, but using them only partially is not a clean model. We agreed to
put a note in the document asking for feedback on this point.

>    3. S contains some schema type IT such that derives-from(IT, ET) and
> derives-from(AT, IT) are true.
> # Otherwise, derives-from(AT, ET) returns false
> </new>


-- 
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, 6 October 2009 21:21:17 UTC

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