W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > October to December 2008

[Bug 6168] Interaction of notQName="##defined" with processContents

From: <bugzilla@wiggum.w3.org>
Date: Fri, 17 Oct 2008 08:48:03 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Kql07-0005FZ-SI@farnsworth.w3.org>

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





--- Comment #1 from Michael Kay <mike@saxonica.com>  2008-10-17 08:48:03 ---
Further thoughts on this. There now seem to be four ways of controlling what
happens when a wildcard matches/does not match a global element/attribute
declaration:

strict: validate if defined, error if not

lax: validate if defined, untyped if not

skip: untyped if defined, untyped if not

notQName=defined: error if defined, untyped if not

One practical implication of making this a fourth option on processContents
(let's say processContents="undeclared") would be that it would affect the
rules for wildcard intersection and union. Currently the rules for attribute
groups with multiple wildcards are pretty strange: you get the intersection of
the allowed namespaces, but the processContents of the first wildcard. Moving
the notQName=defined so it became a processContents option wouldn't suddenly
set the world to rights on this, but it would ensure that you don't end up with
crazy combinations like processContents="strict" notQName="##defined".

(I'm not sure where this leaves notQName="##definedSibling", however - that's
another carbuncle, if you ask me.)


-- 
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, 17 October 2008 08:48:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 6 December 2009 18:13:16 GMT