- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 29 Sep 2006 02:03:36 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2235 ------- Comment #1 from cmsmcq@w3.org 2006-09-29 02:03 ------- 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?
Received on Friday, 29 September 2006 02:03:48 UTC