[
Lists Home |
Date Index |
Thread Index
]
Hi Folks,
A few more thoughts.
1. Constraint Volatility: constraints range from highly dynamic business
rule constraints to static data constraints.
2. Constraint Stack: there are advantages to creating "layers of constraint
checking" based on the volatility of the constraints:
a. Simpler design: since each layer has a
focused set of constraints that it must
address, this leads to simpler schemas.
b. Improved Change Management: since volatile
constraints are isolated it is easy to
replace them with new versions.
[Analogy: the "constraint stack" is analogous to the 7 layer OSI Model.
Each layer of the model addresses specific concerns.]
3. Multi-Schema Design: the current practice is to create one schema to
implement all constraint checking[1]. Preference should be given to
multi-schema designs.
4. Typical Constraint Stack: below is a typical constraint stack. The higher
layers implement volatile constraints. The lower layers implement static
constraints.
Java (layer #4)
Schematron (layer #3)
XML Schema (layer #2)
XML Schema (layer #1)
Example:
A company has employees. This is the current company policy with respect to
employee age requirements:
- the minimum age of an employee must be 16.
- employees under 18 must have parental consent.
Here is the constraint stack:
Java (layer #4) implements the constraint:
verify that the employee has provided a value for <age>
Schematron (layer #3) implements the constraint:
IF <age> is less than 18 THEN exists(<parental-consent>)
XML Schema (layer #2) implements the constraint:
verify that <age> is at least 16
XML Schema (layer #1) implements the constraint:
verify that <age> is a nonNegativeInteger
Naturally, feel free to replace XML Schema with RelaxNG, Schematron with
XSLT, Java with C, C++, etc. It is the layering approach that is of
importance, not the specific technologies employed.
Comments?
/Roger
[1] Importing/including other schemas is effectively a one schema strategy.
|
