[
Lists Home |
Date Index |
Thread Index
]
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
goes...)
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
fancy.)
Cheers
Rick Jelliffe
|
