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

On 12 May 2009, at 06:29 , Costello, Roger L. wrote:

> ...
> Having "lived" for a while with the new <assert> and <alternative>  
> elements, I recommend the working group consider the following  
> changes to them.
>
> ...
>
> PHILOSOPHY (I DIGRESS)
>
> When I make a decision I typically take into account many factors,  
> some of which are not local. For example, I decide whether or not to  
> go to the beach based upon how I'm feeling (local factor), the  
> weather (external factor) and the traffic conditions (again, an  
> external factor).
>
> My point is that making an assertion based on the current element  
> and its descendants (i.e. on local information) is not reflective of  
> how decisions are made in the real world.

Quite true, though I'm not sure the application to validation is  
completely
simple.  Your final decision can depend on many factors, some local and
some non-local.  Similarly, what your software does can depend on many
factors, some local and some non-local.  Validity is just one factor to
consider, and will continue to be just one factor, whether it is  
defined to
be local and relatively straightforward to calculate, or non-local and
Turing-complete.

My point is that life is sometimes complicated, and the fact that your
decisions may depend on non-local factors does not in itself seem to  
provide
a prima facie argument that document validity must depend on non-local
factors.

>
> PREDICTION (UNINTENDED CONSEQUENCES)
>
> Due to the limitation on what XPath can reference, I predict that  
> schema developers will put all assertions on the document's root  
> element. In fact, that is what I currently recommend to people:
>
>   Due to the limitation on what XPath
>   can reference, I recommend all assertions
>   be placed on the document's root element.

That seems unnecessarily restrictive, and seems to assume that we always
know in advance which element will serve as document root.

I suspect assertions will be easier to understand and use if the rule
is:  place all assertions on the nearest common ancestor of the elements
and attributes referred to in the assertion; sometimes that will be the
outermost element, but not always.

>
> RECOMMENDATION
>
> I respectfully recommend the working group remove the restrictions  
> on what XPath can reference in the <assert> and <alternative>  
> elements. For the <assert> element I recommend the XPath be allowed  
> to reference any part of the document (ancestors, cousins, siblings,  
> descendents) as well as external documents using the doc() element.  
> For the <alternative> element I recommend the XPath be allowed to  
> reference any part of the document except descendents as well as  
> external documents using the doc() element.
>
>
> Thank you for your time.

Thank you for your interest in XSD 1.1.

If you would like a formal response from the XML Schema working group,  
you will
want to make your recommendation not in a post to xmlschema-dev but by  
opening an
issue in the W3C's public instance of Bugzilla, as described in the  
'status of
this document' sections of the XSD 1.1 specs:

     Comments on this document should be made in W3C's public  
installation of
     Bugzilla, specifying "XML Schema" as the product. Instructions  
can be found at
     http://www.w3.org/XML/2006/01/public-bugzilla. If access to  
Bugzilla is not
     feasible, please send your comments to the W3C XML Schema  
comments mailing
     list, www-xml-schema-comments@w3.org (archive) Each Bugzilla  
entry and
     email message should contain only one comment.

That makes it easier for the WG to track comments that require a  
formal response.



Speaking for myself, I have a great deal of sympathy for your view:   
allowing
assertions to point outside the current element, or even outside the  
current
document, can be somewhat more convenient for the schema author.  I do  
think
(as others have suggested) that you have overlooked the arguments on  
the other
side relating to streamability, to implementability and implementation  
cost,
and to the conceptual foundations of validity.  The uptake of  
Schematron shows
pretty clearly that in some situations, reference to arbitrary  
locations in
or out of the document does not impose an unacceptable burden; the  
lack of
uptake of Schematron in some application areas seems to show pretty  
clearly that
there are situations where reference to arbitrary locations does  
impose a
burden people are unwilling to accept.  They may be right or wrong on  
the
technical merits, but one idea behind consensus standards is that you  
and
I do not get a chance to impose our views on them.

So far, I have not seen any assertion that requires upward or sideways
reference within the document that cannot be rewritten as a downward- 
looking
assertion on an element nearer the root.  I do not know if any of the  
work
of recent years on XPath evaluation provides a proof that such a  
rewrite is
always possible, although it seems intuitively plausible that it may be.

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.

All of the arguments you bring forward were considered by the WG in
the course of design; unless there is some new information to be  
considered,
it seems likely that when the WG reexamines the problem area they will
reach the same evaluation of the tradeoffs here as they did the first
time, and each time the question has been re-opened since.

Michael Sperberg-McQueen



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

Received on Tuesday, 12 May 2009 15:24:32 UTC