[Bug 4367] Subsumption and assertions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4367





------- Comment #4 from cmsmcq@w3.org  2007-03-06 16:08 -------
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.

Received on Tuesday, 6 March 2007 16:08:32 UTC