This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Hello. I do not know if in XSD 1.1 the WG is examining the problem of restrictions for attribute wildcards. Although when deriving a complex type by restriction the base type definition's attribute uses is automatically inherited by the restricted type, in section 3.4.2 of http://www.w3.org/TR/2007/WD-xmlschema11-1-20070830/ it is stated that the base type definition's attribute wildcard is *not* inherited. Therefore we end up with two different rules for attribute uses and attribute wildcard which are in our mind not only difficult to understand, but also making noteworthy use cases difficult (or even impossible) to deal with. For example, as it often the case, we could decide to provide a ur-type (from which all other types are derived) to define a number of features (among which, for instance, core attributes such as class, title and id in XHTML) that are shared among all subsequent derived types. A very important schema-wide decision could be allowing any attribute using the anyAttribute wildcard. But unfortunately we cannot just place the anyAttribute element in the ur-type, as any subsequent restriction, while maintaining the core attribute set, would remove it. Having or not having an attribute wildcard, therefore, cannot be a schema-wide decision. This is very unfortunate. I can provide a simplified version of the CEN Metalex schema that examines the problem. We would like to allow attributes from external namespaces, such as RDFA. Currently the two examples are not valid, and would become so only by adding the anyAttribute element in all derived types. We strongly suggest allowing element wildcards to be inherited by restriction, if possible directly in version 1.1. Ciao Fabio and Paolo
Created attachment 549 [details] Two schemas importing a common schema that should, but doesn't, inherit anyAttribute. Also, two examples that aren't valid
On our telcon today, the WG classified this issue today as needsAgreement. There was concern over the possibility of changing the interpretation of existing schemas; FV proposed that inheritance of wildcards be under control of an attribute which defaults to meaning 'no inheritance' so that existing schema documents do not change interpretation. The upshot was that there was neither consensus that we should do this, nor consensus that we should not. So: needsAgreement. The chair warned that in view of the calendar the passage of time, and the editorial backlog, it is not certain that we will get changes drafted and agreed for all items classed needsDrafting, let alone other items, so that most items marked needsAgreement are at risk of being closed without change with the disposition LATER or WONTFIX.
The XML Schema Working Group discussed this issue at its teleconference of 13 June 2008. There was some support for the idea proposed, but the consensus of the group as a whole is that we cannot provide this new feature without a high cost in delay. So with some reluctance, the WG agreed to close this issue with a disposition of LATER, in the hopes of coming back to it at some future date. There was also some hope that the xs:openContent construct might at least mitigate the inconveniences mentioned in the original bug report. Fabio (and Paolo), as the originator(s) of this proposal, the WG would be grateful to you if you would consider this disposition of the issue and let us know by closing the issue that you are willing to accept the WG's decision, or by reopening it that you are dissatisfied and wish the WG to reconsider, or wish to appeal the WG's decision to the Director.