[
Lists Home |
Date Index |
Thread Index
]
Roger,
I don't buy into any of this layering of constraints!!
Look here - its 2004 going on 2005 and we're still all thinking like COBOL
programmers. COBOL had copybooks, C had .h files and structs, and Java has
similar, and now XML is supposed to have XSD. You can add EDI to the list
too.
It's bogus IMHO.
The real way forward is to put *context* front and center. Context drives and
is at the heart of the constraint checking - and being able to manage this and
make it scalable. This is what we've learned from EDI especially, and then the
ebXML phase 1.
Therefore you need to centralize your constraint information and make it so that
you have a unified controlling mechanism.
Notice we already heard about a government proejct with three different
definitions of the same thing based on context. And what hurts them is that
they do not have those centralized in a registry that can be managed.
So - in ebXML phase 2 here - we're adding context. Starting with BPSS V2 - you
can manage this and propogate it - and especially down into the process steps
of a BPM - so that tools like CAM can use that context to determine the
constraints that apply directly.
As we've already learned - there's no such thing as an immutable constraint.
But in CAM you can separate things into inline predicates that come with an
included base reference structure, and then override or augments those with
context driven rules / and / or you can pull rules from a registry of
definitions.
Essentially what you have is a holistic way to tailor this to your environment -
but one where the context is not embedded and hidden into source code and
back-end programs - but is exposed, visible and dynamic - up front and across
the whole integration space.
In the CAM tutorial you'll find a slide that quotes from 1623 and when they were
putting the first dictionaries together - having invented the printing press -
they understood about context and meaning back then - but we're still only just
figuring out how to make markup effectively manage this - 400 years further
on!
Cheers, DW
===========================================================================
Quoting "Roger L. Costello" <costello@mitre.org>:
> 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.
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
