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

Rick Jeliffe wrote (in a related thread):

> Michael Kay wrote:
> 
> > I think the working group felt that
> > introducing context-dependent validation (where the validity of a 
document
> > depends on factors other than the schema and the instance document) 
was a
> > risky architectural innovation, and possibly a step that would be 
later
> > regretted. 
> 
> So they actually had no reason? Just some vague possibility.

Michal Kay wrote:

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

Yes, exactly.  I had been meaning for sometime to respond to Rick's query, 
an the above is exactly the answer I'd give.  Let me add a bit.

As MK says, the context independence of schema types has real value in 
applications like XSLT and XQuery;  it's not just something that seems 
appealing in the abstract.

That said, it's also true that this design decision is a compromise that 
makes XSD 1.1 less useful for certain applications.  The working group was 
well aware of these tradeoffs.  We explicitly considered use cases such as 
the ones that Roger has proposed.  We were aware that certain constraints 
would tend to wind up on the root type, if assertions are used, and that 
this was at best ugly and at worst impractical.

I don't want to speak formally for the working group, but I can tell you 
why I'm comfortable with the tradeoff we adopted:

* Schematron is very good at the sorts of constraints, often derived from 
business rules, that tend to involve information that is conceptually, and 
often physically, widely dispersed in a document.  E.g., if the value of 
any item in a purchase order is > $1M then the shipper must be our insured 
shipper.  XSD is more focussed on structural constraints, typically those 
that are relatively localized in the document tree.  XSD also provides 
abstractions like types which, as Mike shows, have value for things like 
return types in XQuery functions.

* <xsd:assert> was inspired by the similar facility in Schematron, but XSD 
is not a replacement from Schematron.  There have been reports of people 
who use XSD for structural constraints and to drive databinding, and 
Schematron for business rule checking.  I think that's still a good way to 
go.    Why have <xsd:assert>?  Because there are lots and lots of 
constraints it can check that fit beautifully with the type system.  If 
you have a type that happens to have attributes @min and @max it's great 
that you can now enforce, as part of the type definition @max>=@min. There 
are many others.

So, while the design chosen is surely a tradeoff, it was made with some 
care, and with real awareness of the use cases not addressed.  I remain 
comfortable that it is on balance a good choice.  I hope it's clear that I 
also think there are very good reasons why Schematron's facility is far 
less restrictive.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

Received on Tuesday, 12 May 2009 14:43:54 UTC