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 rules for Schema Component Constraint: Derivation Valid (Extension) (and similarly, Restriction, require: 1.6 The {assertions} of the {base type definition} is a prefix of the {assertions} of the complex type definition itself. This constraint appears to be true by definition. Conversely, the rules for type subsumption (Schema Component Constraint: Complex type definition actually restricts) make no mention of any requirement for the assertions on B to be a superset of those on R. This is where the rule should appear. A couple of other points: (a) defining a subset relation on sets of assertions assumes the existence of an equality relation on assertions, and therefore on XPath expressions, which has not been defined; (b) modelling the set of assertions as an ordered list and requiring a sublist rather than subset relationship seems to be a quite unnecessary complication - as with the rules for deriving any from sequence, it seems to be a rule articulated by an unimaginative implementer who knows how to handle lists and doesn't know how to handle sets.
Looking at this more closely, while the "actually restricts" relation between types clearly necessitates some subsetting relationship between the assertions defined on the two types, I believe that this relationship always exists in places where the "actually restricts" relation is appealed to.
> This constraint appears to be true by definition. Is it true by definition in "born binary" components? I would think not. Noah
You're right, Noah. Bug withdrawn.
I think your remarks on the choice of a sub-list vs. a subset relation between base and derived type, and on the fact that no equality relation has been defined by XPath 2.0 for XPath expressions, are astute and deserve an answer. On the other hand, I think the current design is defensible, and worth explaining. We often use lists instead of sets for components which may lack names, in order to ensure that we can generate SCDs (schema component designators) for them; indeed, XML Schema 1.1 has changed some components (e.g. annotations) from set to list precisely for that reason. But because lists don't require de-duping, they also allow us to avoid the question of XPath identity and assertion. If the same assertion occurs more than once in a list, no harm is done. A smart implementation may notice that an assertion is identical to, or guaranteed to have the same answer as, some assertion already checked; a naive implementation may save itself the trouble of detecting identity or equality or equivalence among XPath expressions, at the expense of possibly checking the same thing more than once. That is, it is safe to treat each distinct assertion element as providing a distinct assertion. If it becomes important to formulate an identity condition for assertions, I would incline to treat XPath expressions as strings and say that assertions X and Y are the same assertion if and only if they are the same sequence of characters, in the infoset of the schema document. Distinct XPath expressions may, on this account, have essentially the same parse tree if they vary only in whitespace and comments, and XPath expressions with larger differences may have the same abstract syntax tree or be guaranteed to return the same results. We should probably make clearer that the XPath expression in the {test} property is formally a sequence of characters. That could be done by changing the words {test} A restricted XPath expression corresponding to the actual value of the test [attribute]. to {test} The actual value of the test [attribute]; this will invariably be an XPath expression. I won't reopen this bug to track that idea, though.
>I would incline to treat XPath expressions as strings and say that assertions X and Y are the same assertion if and only if they are the same sequence of characters That's not actually a sufficient condition: the two XPath expressions must also have the same static context (for example, in-scope namespace bindings).