2235 2005-09-14 19:36:27 +0000 R-243: Can an attribute prohibited by restriction be added back through a subsequent extension? 2009-04-21 19:21:39 +0000 1 1 1 Unclassified XML Schema Structures: XSD Part 1 unspecified All All CLOSED FIXED important, hard resolved P4 normal --- 1 sandygao cmsmcq www-xml-schema-comments oldest_to_newest 6263 0 sandygao 2005-09-14 19:36:27 +0000 The REC says in clause 1.5 of Schema Component Constraint: Derivation Valid (Extension): Note: This requirement ensures that nothing removed by a restriction is subsequently added back by an extension. That is where the REC tries to answer "no" to the question of "whether an attribute [or element] removed by restriction could be added back in an extension." However the constraint itself, in my view, fails to achieve this, so processors which allow it are not broken. I think we should fix this one way or another: 1. No constraint on re-introduction; 2. No re-introduction of any kind (apparent intention of current REC); 3. Re-introduction of unchanged originals only (what the current REC actually says)? See: http://lists.w3.org/Archives/Public/www-xml-schema-comments/2004JanMar/0005.html 12181 1 cmsmcq 2006-09-29 02:03:36 +0000 It's hard to reconstruct all of the arguments that led to the requirement that in principle it should be possible to derive any type in three steps from xsd:anySimpleType: the first non-primitive ancestor, then one extension step, then one restriction step. So I'm diffident about this analysis. But it seems to me that flavor 3 (reintroduction of unchanged originals is OK) is not only what the status quo says, but what is most useful to say. Given a chain of derivations from some type T, in which restrictions and extensions both occur, it's useful to know that if any attribute A is optional in type T, with a binding to a specific simple type S, then in any type T' derived from T in any number of steps, that A may be present or may be absent, and if present it will always have type S, or a restriction of S. That's guaranteed by 3, and by the formulation of the actual rule. It's not guaranteed by 1, which I dislike for that reason. The constraint (2) actually formulated in the Note (once gone, nothing comes back -- reminds me of J. K. Rowling's rules about magic and death) amounts to saying yes, not only will A always have S or a restriction of S if it's around, but the portions of the type hierarchy where A is allowed will form a tree, not a forest. I hate to say of any fact that it's uninteresting (it seems to suggest a failure of imagination), but this doesn't seem particularly relevant to any story about types and the substitutability of values. When considering type coercions and the acceptability of a value, we typically consider two types: the one expected and the one encountered. The details of the chain connecting them (in a name-based system) isn't relevant, only which invariants are guaranteed to hold between these two types. I think the correct fix is to revise the Note to say "nothing removed by a restriction is subsequently added back by an extension with a conflicting type assignment" or "... in an incompatible way". Is that plausible? 12571 2 cmsmcq 2006-10-21 20:27:35 +0000 On 20 October 2006 the WG accepted the suggestion in comment #1 and agreed to close the issue accordingly. The note in question has been modified to say "nothing removed by a restriction is subsequently added back by an extension with a conflicting type assignment"; the change is now in the status-quo document and will appear in due course as part of the next published working draft. 12618 3 noah_mendelsohn 2006-10-27 14:57:26 +0000 > "nothing removed by a restriction > is subsequently added back by an > extension with a conflicting type > assignment"; At risk of taking time at a valuable point in our process, is there any issue with adding something back in a way that is inconsistent with respect to something other than type? An in consistent value constraint, perhaps (Base has fixed="a", nth step derivation has fixed="b")? I haven't researched in detail. If others who are expert think there's no issue here, then let's move past this very quickly. I'm just raising it in case anyone with more detailed knowledge than I have says: "oops, right, badly broken" Thanks. Noah