RE: Declarative constraints for XML documents

Mike Spreitzer wrote:
>>Declarative constraints are what schemas are for!  The W3C's XML Schema
>>Working Group has already accepted as a requirement the ability to put
>>"application-specific constraints" into schemas (see Structural
>>requirement 5 in
>><http://www.w3.org/TR/1999/NOTE-xml-schema-req-19990215>).  Let's not
>>architect things that are "schema-like" but "not schemas"; let's make
>>schemas able to say what we need them to say.
>>
>>Mike

The thread has followed a little convoluted path since I posted my original
query.  The original query was primarily targeted to currently available
technologies to solve the specific problem, however I agree with you that
the fundamental intention does fall under the requirements in the Schema
working group and that the Schema would be an ideal place to express these
constraints.  

The current working draft does propose a good selection of constraining
facets for datatypes, regex or patterns for strings, minInclusive et al for
ordered, list of acceptible literals for enumerations.  What would complete
the datatypes constraining facets would be support for a script type facet
that would contain a JavaScript (or alternate) fragment and maybe an <and>
or <or> to allow logical combinations of constraining facets.  Of course,
you would want to avoid the script facet if one of the other facets could
express the constraint since a schema aware editor could give more direct
guidance for violation of a minInclusive constraint for example.  

The next level up is a constraint on an element that would constraint, for
example, the product of two attributes to be positive.  These types of
constraints would tend to be so open ended that the only reasonable solution
is to be able to attach a series of script fragments that would be passed a
reference to the element during processing.  This type of constraint could
still be validated by event based parsers.  A schema aware editor could only
enforce this type of constraint when exiting an element.

The next level up would be a constraint on an element that constrains the
content of elements that it contains.  This type of constraint again would
be best expressed in a script language, but could not be validated by an
event based parser since at least the element and all of its children would
need to be accessible through the DOM.

There would need to be some mechanism for a processor to indicate what types
of facets or constraints it can enforces and a mechanism for an application
to indicate what facets or constraints it requires to be enforced, so that a
lightweight processor (or an application that did not want to pay the
processing cost) could forgo regex processing or script evaluation.

Received on Wednesday, 18 August 1999 14:09:48 UTC