W3C home > Mailing lists > Public > xmlschema-dev@w3.org > March 2006

Re: [xml-dev] Two Questions - on XML Schema

From: Rick Jelliffe <rjelliffe@allette.com.au>
Date: Fri, 10 Mar 2006 19:55:34 +1100
Message-ID: <44113F06.10502@allette.com.au>
To: xml-dev@lists.xml.org
CC: Paul.V.Biron@kp.org, ElektonikaMail@frink.w3.org, xmlschema-dev@w3.org, xmlschema-dev-request@w3.org

Michael Kay wrote:

> It might be that we've reached the stage where we can't afford to do 
> things
> properly so we have to do them cheaply.

I thought we came to that stage ten years ago (i.e. XML)!  Wrong 
audience on XML-DEV Michael :-)

> If that's the case, then this i
> probably the right way forward. However, one needs to be aware of its
> limitations. For example, if there are two possible content models for an
> element and you want to control which one to use based on an 
> attribute, then
> you have to define the union of the two content models and design XPath
> expressions that implement two permitted subsets. That seems pretty 
> unusable
> to me.
I don't think so. It means that the content models can become much 
looser, with the specifics
of order and occurrence and co-occurrence dealt with by at the 
constraint level.

 From that POV, generalizing <all>'s cardinality is probably exactly the 
right direction for XSD.

Recently I have been working with some people on constraint 
traceability: that all constraints
implemented in a software system needs to be justifiable and traceable 
to a business requirement.
The corollary is that good technologies for agile systems don't force 
extraneous constraints
down your throat: you have to pay for these. In the case of schemas, for 
example, whenever
a schema language forces you to specify an order for unordered data, 
this is a non-business
-requirement-traceable constraint, which is a cost ultimately (or so the 
theory we are looking at
XSD + Schematron fits well into this kind of mentality. Indeed, it is a 
conservative approach:
RDBMS have schemas and constraints separate, UML has its constraint 
language separately.
For this kind of approach, a sign of success for the basic structure 
language is that it allows
modeling as *few* complex constraints as possible: broad picture, rough 
strokes, containment.
Then the sign of success of the overlaid constraint language is how well 
and directly it can
model or state business requirements on the simple superstructure.

As a concrete example, think of schema evolution: having order and 
cardinality dealt with
by a constraint layer rather than at the schema layer allows much more 
flxibility in variant schemas
and versioning, exactly in the kinds of areas where complex type 
derivation is fragile; in other words,
to an extent, the fragility and unsatisfactoriness of extension by 
suffixation and the limitations on
derivation by restriction can be reduced by moving 
buasiness-rule-contingent constraints to a higher
level. So I think Schematron (or a separate constraint layer) does more 
than just address tedious co-occurrence constraint requests, it can also 
allow type derivation to fit more comfortably by stuffing less into it.

> To my mind, grammar-based constraints and value-based constraints 
> should be
> much more closely integrated than this. And I don't think it's 
> impossible.
I don't think its impossible, but I think its the wrong way to go. I 
think grammars should just
be dropped in favour of paths entirely. It is silly to have one paradigm 
for schemas
then have to use an entirely different one for data access. Of course, 
then you get problems
with completeness detection, databinding, interface generation, etc.

> That doesn't preclude the needs for generalized XPath-based 
> constraints in
> the schema, of course.
And it may well be that path constraints are ultimately best placed at 
some XQuery kind of level:
multiple documents. Also, there is enormouse scope for debate on which 
kind of logic to use, for
any new rule based system. (Schematron uses if..then  logic, nothing 

Rick Jelliffe
Received on Friday, 10 March 2006 08:56:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:56:09 UTC