This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In section 3.4.3 we have a lexical representation rule: 2 If <openContent> is present and has mode ≠ 'none', then there must be an <any> among the [children] of <openContent>. I would have expected to see also the converse rule: 2b If <openContent> is present and has mode = 'none', then there must be no <any> among the [children] of <openContent>. As written, it seems that an <any> child is allowed, and is ignored.
This seems like an unfortunate lapse into paternalism. The existing rule 2 prevents a semantic train wreck: if it's violated, the schema document has no interpretation. The situation outlawed by the proposed rule 2b, on the other hand, has a completely coherent interpretation. It's analogous to an "if (false) then ..." construct in most programming languages, or an XSLT template with mode="m", where mode m is never used. In practice, when experimenting with changes in a schema, I expect it to be handy to be able to turn open content off in a particular type, while retaining the wildcard in case I later want to go back to allowing open content; this is most important, of course, in cases where the wildcard is complicated and might be onerous to reconstruct from scratch. (That's also when I use mode="nonesuch" in my XSLT stylesheets.) Speaking for myself, I'd rather not make this change.
I can't see the analogy. Specifying mode="none" with a wildcard seems like nonsense to me: "there is no wildcard, and here it is". It's like allowing <e xsi:nil="true">content</e> - if an element is nilled, then it can't have content.
(In reply to comment #2) > I can't see the analogy. Specifying mode="none" with a wildcard seems like > nonsense to me: "there is no wildcard, and here it is". It's like allowing <e > xsi:nil="true">content</e> - if an element is nilled, then it can't have > content. Isn't it more like "nothing is allowed to satisfy this, hence a wildcard present represents inaccessible optional content"? (Much like content that gets maxOccurs zero.)
On that theory it's "paternalistic" that we don't allow a simple type to define "inaccessible" attribute uses.
MSM: remove rule 2 as quoted -- it's not necessary. SG: what about mapping rules? RESOLUTION: adopt MK's 2b rule.
The change agreed upon during today's WG call has been integrated into the status-quo documents on the server. I'm marking the issue resolved, accordingly. Michael, if you would do the honors, please? Thank you.