RE: [XML Schema 1.1] I respectfully recommend these changes to <assert> and <alternative>

> > (Paraphrasing) By allowing the XPath in an <assert> element 
> > to reference ancestors, cousins, and siblings it will break XPath.
> 
> I don't recognize or recall the comment that you claim to be 
> paraphrasing.


I interpreted the following statement from Michael Sperberg-McQueen as meaning "Allowing XPath expressions to reference ancestors, cousins, and siblings will break XPath":

   Even if it could be shown that the 
   downward-only restriction on assertions 
   caused a loss in expressive power, it 
   might nevertheless be plausible to argue 
   that the cost in expressive power is outweighed 
   by other factors. In the absence of any 
   demonstrable loss of expressive power, I 
   predict that the compatibility issue for 
   XPath 2.0 and related specs is a clinching 
   argument:  on the one hand, we can be 
   compatible with XPath 2.0 et al., or on 
   the other, we can be incompatible in a way 
   that provides, as far as we know, some 
   greater convenience but no additional 
   expressive power. Even if the incompatibility 
   provided some gain in expressive power, many 
   people would turn down that choice because the 
   cost of incompatibility with XPath is very high.  
   But without any gain in expressive power?  I think 
   the inconvenience of downward-only assertions is 
   minuscule compared to the inconvenience of 
   having to rewrite XPath 2.0 and the accompanying 
   specs, or of having an incompatibility that 
   makes XSD 1.1 unusable for them.


In particular, these words led me to my interpretation:

    "incompatibility with XPath"

and

   "inconvenience of having to rewrite XPath 2.0"


How is it that an XPath expression referencing ancestors, cousins, and siblings in an <assert> element is incompatible with XPath 2.0? And would require rewriting XPath 2.0?


/Roger

Received on Wednesday, 13 May 2009 13:04:26 UTC