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

On 13 May 2009, at 07:03 , Costello, Roger L. wrote:

>
>
> 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?

The use of ancestor and sibling axes in XPath expressions is not
in itself incompatible with XPath 2.0 or related specs.

Making the validity of an element against a given type vary with
the context in which the element is found (which would be a
consequence of evaluating assertions against the entire tree instead
of just against the subtree in question) would, we have been told,
be incompatible with a basic assumption currently made by those specs.

As Michael Kay put it in an earlier message in this thread:

     It's a conscious design decision that when you define what
     constitutes a valid book, the definition should be context- 
independent:
     if it's a valid book in one situation, then it remains valid in
     any other situation.

     XSLT and XQuery rely on this context-independence - if a
     function returns a valid book, or if you select a valid book
     by XPath navigation, then the element can be used in any context
     that expects a valid book, without having to be revalidated to
     ensure it's still valid in the new context.

I'm sorry to find that my earlier message touching on the compatibility
issue was insufficiently clear.  I seem to have assumed, in writing
it, that earlier contributions had already made clear the nature of
the compatibility issue raised by Roger Costello's proposal.  My  
apologies
to any readers bewildered as a result.

Just to try to put it onto a bumper sticker:

     The QT specs rely on the type-validity of elements being
     independent of context, so that if I copy a valid element of
     type T, and place it in a new context (say, a result document),
     the copy is also a valid element of type T.

     The proposal to change the rules for evaluating assertions by
     making the entire document available would make type-validity
     of elements depend on context.  (If I assert parent::*[@xml:id
     = 'dada'] to ensure that an element of a particular type is
     valid only if its parent element has @xml:id = 'dada', and
     copy it as a new child of an element with @xml:id='mama', the
     copy won't be valid.)

     The proposal is therefore be incompatible with the QT specs.

It may be that the QT specs were unwise to build anything on the
context-independence of type-validity.  It may be that some
workaround can be found.  It may be that there will be pie in the
sky, by and by.  And it may be that the opposite is true.
YMMV.

-- 
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************

Received on Wednesday, 13 May 2009 21:49:13 UTC