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

[Bug 13674] [XQ30] schema-element() types behave differently in different modules.

From: <bugzilla@jessica.w3.org>
Date: Fri, 05 Aug 2011 23:07:22 +0000
To: public-qt-comments@w3.org
Message-Id: <E1QpTUA-00078o-3S@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13674

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> 2011-08-05 23:07:19 UTC ---
I think you are describing a particular instance of what is actually a more
general problem. Although we define that a type named T must be identical in
every module, it remains true that an element may be valid against type T in
the context of one schema S1, and invalid against the same type T in the
context of a different schema S2. Substitution groups are one reason for that;
strict and lax wildcards are another; types derived by extension are another
case; in XSD 1.1, notQName in wildcards provides yet another. 

Saxon's approach to the problem you describe is to extend the consistency
constraints so that in all static and dynamic schemas used for a particular
query, an element declaration E must have the same substitution group, and a
type T must have the same set of types derived by extension.

(As for wildcards, I think I avoid making inferences about wildcards that might
be invalidated if element declarations are added to or removed from the schema.
But I wouldn't be 100% confident I've got this right.)

-- 
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 Friday, 5 August 2011 23:07:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:36 UTC