- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 27 Nov 2007 14:32:48 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5289 Summary: "##defined" in wildcards Product: XML Schema Version: 1.1 only Platform: PC OS/Version: Windows XP Status: NEW Severity: normal Priority: P2 Component: Structures: XSD Part 1 AssignedTo: cmsmcq@w3.org ReportedBy: mike@saxonica.com QAContact: www-xml-schema-comments@w3.org I've started looking at the "##defined" keyword in wildcards, and in particular its impact on type subsumption. (This comment relates to a priority feedback request). My current feeling is that this feature is a bad idea because it causes unpredictable side-effects. It means that the meaning of a type is impacted by the set of element/attribute definitions that the schema processor has available and is capable of resolving against, which is intrinsically unpredictable (and may be rapidly changing) in many processing environments. Arguably, for simple validity checking (does a name match a wildcard?) this is unlikely to make much of a difference most of the time. But it can have other effects: for example adding a new element declaration to the schema can invalidate the type subsumption relationship between two existing types in the schema, and the processor therefore needs potentially to re-evaluate such relationships every time a new element or attribute is added. Arguably the "effect at a distance" of "##defined" is not new, it already exists for processContents="strict". However, I believe that the type subsumption rules for processContents="strict" do not take into account the actual set of element declarations that a wildcard is capable of matching, because they do not affect local validity of an element against the wildcard. I might be able to accept "##defined" if the type subsumption rules were based on an open-world model, that is an assumption that an element declaration exists for every possible element name.
Received on Tuesday, 27 November 2007 14:32:59 UTC