This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The declarations <xs:anyAttribute/> and <xs:anyAttribute notNamespace=""/> are to all intents and purposes equivalent; both allow any attribute in any namespace. Yet the schema component model maintains a distinction between them. It provides three {variety}s of Namespace Constraint where two would be sufficient; it is not necessary to provide the option {variety}="any" because it is equivalent to {variety}="not" with {namespaces} equal to the empty set. Having three varieties where two would do unnecessarily complicates the rules for wildcard validation, subsets, union, and intersection. It also unnecessarily complicates an implementation, because an implementation that exposes the schema component model is required to maintain this meaningless distinction. Note: I think it would also ease the exposition of these algorithms if the Namespace Constraint had two properties, {allowedNamespaces} and {disallowedNamespaces}, with a rule that one of them must be empty; one could then dispense with {variety}.
<xs:anyAttribute notNamespace=""/> is currently not allowed, as it will not pass bullet 2 of "3.10.6.1 Wildcard Properties Correct": "2 If {variety} is not, {namespaces} has at least one member." Agree that 2 variety values (or 2 properties) would work and certain things can be simplified, but - Mapping <xs:anyAttribute namespace="##all"/> to "not + {}" or "disallowedNamespaces={}" could also be counter-intuitive to readers. - API compatibility. Schema model APIs that support schema 1.0 probably already defined a method like getVariety() on wildcards and people would expect ANY returned. The API concern is related to the implementation discussion in the bug report. If the implementation doesn't intend to expose a schema model API, then it can choose to have 2 variety values internally. If it does expose such an API, then it probably already does so for schema 1.0 and would be concerned about compatibility.
>2 If {variety} is not, {namespaces} has at least one member." Thanks. I missed that rule. This means that there is no redundancy in the model, which deals with the main criticism in the bug report. It would seem a good idea to add a similar rule at the XML level, as a constraint on the length of the notNamespace list type in the S4SD. Alternatively, add a mapping rule so that notNamespace="" is allowed and maps to {variety}=any. Regarding the compatibility issue, I think it's quite hard to decide what is needed for compatibility in the absence of a concrete API. My feeling is that we are describing a data model, not an API. An API is a view of a data model, and changing the data model does not by itself make it impossible to provide a view that is backwards compatible. And I don't think the change I'm suggesting would make it more difficult to provide that view - it's already going to require some creativity to extend an API that previously only allowed one excluded namespace so that it now allows a set of excluded namespaces. I think the model I'm proposing is simpler and would reduce the complexity of the spec, but if the editors think the change is too disruptive then I won't waste the WG's time on the issue.
At the 2008-10-24 telecon, the WG adopted a proposal that implements the suggestion: > It would seem a good idea to add a similar rule at the XML level, as a > constraint on the length of the notNamespace list type in the S4SD.
The proposal adopted can be found at (member-only): http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.omni0810.html