[
Lists Home |
Date Index |
Thread Index
]
XML Schema is just kind of static specification.
When I will asure, that constraints will work everywhere and
every time I definitely will put them to Schema from the beginning.
And it doesn't matter of what kind of constraints we are speaking:
minOccurs, maxOccurs, pattern and etc.
If some constraints is context dependant by nature
I would be use business rules for generating new schema on run-time.
Some folks argued about useless min and max constraints in schema,
but think again: schema is a business specification
and important thing is it's understandable for people and for computer.
That means you can generate all necessary functionality from
specification (Schema) by smart generator.:)
There is some stuff from:
OASIS Content Assembly Mechanism TC
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cam
-----------------------------------------------------------------
Traditionally people approaching XML and e-business anticipate that all
that is required is a schema of some form, and that the complete
interchange is thereby described and their business integration
problems are solved. Unfortunately schema is not engineered and
designed to solve this complete problem, instead it only describes
in a limited fashion the information model for document content.
So which ever kind is selected, W3C Schema, XML DTD, RELAX, or
even EDI structures, these only provide the model of the
complete 'set' of all possible uses of the structure.
This kind of validation is suitable for detecting basic structural
errors within content where performance requirements preclude more
extensive and rigorous error checking. An extreme example is found
in something like an 850 EDI Purchase Order, and its XML schema
equivalents, where there are literally thousands of possible
permutations permissible from a single schema instance.
Consequently a transaction can be valid for the schema checks,
but fail more extensive checks of the information integrity.
The result is that there is no way to provide consistent
replicatable interchange specification using Schema or DTD.
CAM mechanism that brings together the business implementation detail
and relates it directly to the structural permutations.
These problems are obviously not new, and we know that a declarative
approach leads to a finite set of implementation points,
without requiring to necessarily state all possible combinations
procedurally.
Therefore our CAM approach adopts a declarative approach, and
as a bonus this also happens to be how people logically address
business definitions themselves. You state what rules apply and
then you expect the machine to take those and apply them logically.
So a declarative approach is much more intuitive and naturally
familiar to crosscheck and verify for business users.
The CAM mechanism specifically allows the use of declarative
predicates to be applied to structural components described by
the transaction structure. Notice that the transaction structure
can be provided by Schema, DTD, simple XML, or even EDI and legacy
structures; and the CAM approach works by combining these predicates
with stating input / output path locations using XPath syntax.
This ability of CAM to work independently of any flavour of structure
language - DTD, Schema, EDI, and so on, is a key feature.
Notice that XPath itself, by providing structure reference pairs,
is in fact independent of XML, since the structure node names
referenced in the XPath syntax need not be of an XML structure,
but will work against any formal structural system that uses explicit nodes.
Using XPath and declarative predicates in this way allow CAM
to state the MIG (message implementation guidelines) in a machine
accessible format. Notice that such predicates require parameter
values at design and runtime to provide explicit context.
For example, if my CAM template provides for both USA and
UK mailing address formats, a business process will need to know
explicitly which to use.
Therefore CAM provides the means to couple to the business context
of the Business Process Mechanism (BPM) of the implementation stack,
and this will include a set of partner parameter profile context values
and link from the BPM itself.
Using this mechanism allows for localization and substitution structures
to match the business transaction needs at run-time.
<BusinessUseContext>
<Rules>
<default>
<context>
<!-- default structure constraints -->
<constraint action="makeRepeatable(//SoccerGear)"/>
<constraint action="makeMandatory(//SoccerGear/Items/*)"/>
<constraint action="makeOptional(//Description)"/>
<constraint action="makeMandatory(//Items@CatalogueRef)"/>
<constraint action="makeOptional(//DistributorID)"/>
<constraint action="makeOptional(//SoccerGear/DeliveryAddress)"/>
</context>
</default>
<context condition="token='//SoccerGear/SupplierID' and contains(value,'SuperMaxSoccer')">
<constraint action="makeMandatory(//SoccerGear/DeliveryAddress)"/>
</context>
<context condition="token='%DeliveryCountry%' and contains(value,'USA'">
<constraint action="useChoiceByID(//SoccerGear/DeliveryAddress(#USA-Street))"/>
</context>
<context condition="token='%DeliveryCountry%' and contains(value,'APO'">
<constraint action="useChoiceByID(//SoccerGear/DeliveryAddress(#USA-APObox))"/>
</context>
<context condition="token='%DeliveryCountry%' and contains(value,'CANADA'">
<constraint action="useChoiceByID(//SoccerGear/DeliveryAddress(#Canada))"/>
</context>
</Rules>
</BusinessUseContext>
-----------------------------------------------------
Maybe it's time to start think about semantic driven architecture
in context xml based application.
Good luck,
Vladimir
> [Jonathan Borden]
>
> > Joe English wrote:
> >
> > > And I'm somewhat suspicious of the above examples, too.
> > > I have a friend with eight grandparents. Some people have
> > > six or more digits per hand. Polysomy is not at all infrequent.
> >
> > Right. Sometimes we want our models to capture every instance of foo...
> > other times we want to flag instances for special attention.
> Chromosomes=46
> > would be a fine cardinality for "humans with normal chromsome number" etc.
> >
>
> I think it is hardly ever needed (or justified) to put these kind of
> contraints into the schema itself. How many times has a designer put a
> constraint of NOT NULL on a database column, only to find it filled with
> values like "-999", because in a practical world, you have to enter the
> record even if the data is not in ideal shape? We had 7-digit phone
> numbers, now we have 10-digit. Most of us in the US do not know our
> extended zip zodes, so they better not be mandatory.
>
> Just because a student is not supposed to be taking more than 7 classes does
> not seem to me to be a good reason for forcing the XML file describing one's
> actual class schedule to contain a max of seven (or eight) <class> elements.
>
> Now if the xml document were going to eventually cause a pre-formatted form
> to be printed, you would need to restrict the number of records, I suppose,
> to avoid overflowing the form. But I am sure that these kind of cases fall
> way outside any 80-20 breakdown or even - I would bet - a 90-10 split.
>
> Even in a case like that, somewhere you or software would have to decide
> what to do in case there were more records than the form could hold. That
> cannot be done with the information in the schema anyway. So why bother
> putting the constraint into the schema in the first case? It doesn't really
> solve the problem it is there to handle.
>
> Cheers,
>
> Tom P
>
>
>
> -----------------------------------------------------------------
> 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://lists.xml.org/ob/adm.pl>
>
|
