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

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

From: <bugzilla@wiggum.w3.org>
Date: Mon, 28 Sep 2009 12:56:12 +0000
To: public-qt-comments@w3.org
Message-Id: <E1MsFm0-0007NS-M5@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=6513





--- Comment #19 from Jonathan Robie <jonathan.robie@redhat.com>  2009-09-28 12:56:11 ---
(In reply to comment #18)
> I believe a better approach to solving this problem would be along the
> following lines:

Yes, I think this is mostly better.


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


In the past, some implementers have objected requiring (2), because they wanted
to be able to determine all type information statically. The main motivation
for the "winged horse" proposal was to at least allow an implementation to use
(2).

We have much more implementation experience now. 


> 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.)

We currently cover this under consistency constraints:

http://www.w3.org/TR/xquery/#id-consistency-constraints

The consistency constraints section doesn't give guidelines for what to do in
the face of an inconsistency, it simply says that the language is undefined in
the face of inconsistencies.

I'm not sure which of three approaches is best:

* must
* may
* defer to the status quo in the consistency constraints section

> 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
>    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>

Nice.


-- 
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, 28 September 2009 12:56:21 UTC

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