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 WG has asked for feedback on applicablity of ##defined in xs:any notQName attributes. It is my opinion that ##defined is too broad, and just because an element or attribute name has been used elsewhere in a schema does not mean that a structure is unlikely in future to be extended with the name (perhaps with different semantics. However, stopping a schema fragment like: <xs:element name='name' type='string'/> <xs:element name='title' type='string'/> <xs:any ???/> matching an instance of: <name>Bob</name> <title>Mr</title> <name>Jumbo</name> seems highly desirable. Hence a keyword of #definedSibling that prevents an xs:any matching the name of any defined sibling is desirable.
WG agrees that adding ##definedSibling is the right way to resolve this issue, while preserving ##defined. Pete, Please let us know if you agree with this direction toward resolution of your issue. If we do not hear from you in the next two weeks, we will assume you agree with the WG decision.
(Apologies for not responding earlier... The domain name I receive these messages on temporarily went out of action.) This is fine with me. Thanks.
Created attachment 550 [details] Shows a change proposal intended to resolve bug 5200 The XML Schema WG today approved the attached wording proposal intended to resolve this issue by defining a ##definedSibling keyword for use in the notQName attribute of wildcards.
With the adoption of the wording proposal attached to this bug report, the XML Schema WG believes that this issue has been resolved. I am changing the keyword field and the record status accordingly. This update to the Bugzilla record should cause email to be sent to Pete Cordell, the originator of the issue, to whom in particular the following remarks are addressed. Thank you for raising this issue. The wording adopted by the WG for this change is shown in the attached document; if you could review it, and let us know whether you think the wording changes shown successfully resolve the issue, we'd be grateful. To indicate your assent to the final wording proposal, please update the Bugzilla record by shifting it from RESOLVED to CLOSED. If something is wrong and you cannot assent, please change the status from RESOLVED to REOPENED (and explain what's wrong). If we don't hear from you in a reasonable amount of time (at least two weeks), we will take your silence as indicating assent.
Over all this looks very good to me. There's just a few things I would like to check before closing it. 1) (The main issue) I don't think it's relevant to discuss attributes when talking about ##definedSibling. Surely an attribute wildcard can never match an already defined attribute sibling anyway. Assuming I haven't missed something (!), it may be appropriate to just remove the bits that mention attributes, or (better?) add a note to say that ##definedSibling is not applicable to the attribute wildcard case. 2) Maybe more of a tool chain issue, but ##definedSibling is not included as part of NotQName in the "XML Representation Summary: any Element" table in 3.10.2. Just to let you know, as I'm not sure whether the above are issues or not, I've left the status as Resolved/Fixed.
As Michael seems to be (understandably) busy I've changed the status of this to REOPENED so that it's not missed when a sweep of that database is done. I hope this is the right thing to do.
Reopening the issue clearly was the right thing to do, since it did make me look at it again and note the remaining points. Since these appear to be editorial rather than substantive, I'm marking the issue editorial (although that keyword applies strictly speaking to what remains now, not to the original issue). That means in turn that this may be dealt with after, rather than before, the WG issues the next working draft.
About the 2 issues raised in comment #5: 1. In fixing bug 6162, ##definedSibling is disallowed in attribute wildcard. 2. ##definedSibling is now included as part of notQName in 3.10.2. Both changes can be verified in the 3rd LC draft: http://www.w3.org/TR/2009/WD-xmlschema11-1-20090130/ Suggest to mark this bug as resolved+fixed.
Looks good. Thanks.