Re: [xml-dev] RE: XML Schema 1.1 Best Practice: Expressing Local Constr

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

At 2010-11-13 09:16 -0500, Costello, Roger L. wrote:
>Suppose a community defines an XML vocabulary for purchase requests.

Your scenario is what we plan for in the OASIS Universal Business 
Language (UBL) committee.

>Here is a sample purchase request:
>...
>The community creates an XML Schema for purchase requests:
>...
>Members of the community create and exchange purchase requests 
>conforming to the XML Schema. However, each member may have 
>additional, local constraints they need to impose on purchase requests.

Absolutely ... this has to be accommodated.  Especially since 
business rules can change even during the course of a single business 
day.  In UBL we recommend users layer on non-syntactic constraints, 
leaving the schema to address only structural and lexical (where 
lexical is really just the structure of a string) constraints.  The 
schema says if the data is correctly found and correctly formed, the 
layered constraints determine if it is correctly valued (whatever 
"correct" means for any particular trading partner or even the 
correct time of day as when tendering periods expire).

And in addition to business rules, when creating a global business 
vocabulary different communities will have different extensions 
wherein they want to keep their own information.  In UBL we create a 
single extension point under which communities put their extensions 
in such a way that systems not recognizing the extension will still 
validate that part of the schema that is "standard UBL".  Thus if 
someone in community A sends a document to someone in community B, 
that document won't be rejected for syntactic reasons just because 
the extensions of both communities are different or non-existent.

Just like a paper invoice:  when one is received in the postal mail, 
any extra information is ignored.  Any required information that is 
missing is assessed regarding whether or not it is still worthwhile 
to process the paper document.  Nothing magically changes when using 
XML, so the XML needs to be designed to mimic what happens in the 
paper world.  We believe we've achieved that in UBL.  Just as the 
schema determines everything is found and formed correctly, one finds 
and "parses" the content of the paper document received in the 
post.  If it isn't properly found on the page or properly formed on 
the page, the paper is rejected.  If it is, then business constraints 
are layered on top of what is conveyed on the paper.

>For example, one member has this business rule:
>
>     Level 1 managers can only sign off on purchase
>     requests under $10K.

Or, "the cheque bounced this morning, from noon on he only pays cash".

>Below are two approaches that the member may use to enforce its business rule.
>
>------------------------------------
>APPROACH #1: Override and Constrain
>------------------------------------
>
>One approach is for the member to create an XML Schema that 
>overrides the element declaration for purchase-request.

Difficult to respond to quick changes.

Difficult to specialize with a layered set of constraints to reuse 
the schema in different business scenarios.

>Using this approach the member validates purchase request XML 
>instance documents against its own XML Schema, not the 
>community-defined XML Schema.

Or possibly even different schemas for every trading partner.

>----------------------------------------------
>APPROACH #2: Supplement and Pipeline Validate
>----------------------------------------------
>
>A second approach is for the member to create a supplementary XML 
>Schema that expresses the business rule:
>...
>Using this approach the member validates purchase request XML 
>instance documents against the community-defined XML Schema as well 
>as its own supplementary XML Schema. An alternative to the 
>supplementary XML Schema is to use Schematron.

The Danish government went the Schematron route.

My implementation of CVA goes the Schematron route.

>Those are two approaches. What other approaches could the member use 
>to implement its local business rule?

Direct custom program checking:  accessing online credit report 
services, database lookups, etc.  Business relationships are *so* 
complex.  XML is a syntactic interchange specification.  I think it 
is reasonable to have the schema solely responsible for the syntax 
and not the content.  In UBL we don't even have code list 
enumerations in schema expressions ... they are layered on using 
genericode and CVA files.  The set of valid codes in a code list can 
also be very dynamic.

But YMMV ... you may be constrained to only a single pass validation 
of the content.  In which case you only have a hammer and everything 
looks like a nail and you put everything into the schema.  This can 
be very inflexible.

I'm not saying its "wrong" to use the schema.  But in your example of 
a business document and the real-world realities of changing business 
rules, just think of the ripple effect of having to change something 
as fundamental as the schema when things change.  Some 
development/production cycles take months, not minutes.  And you want 
a *lot* of testing when dealing with documents related to money.

With UBL developers can create very stable environments for their XML 
with the published (or customized) UBL schemas not changing because 
they constrain only the syntax and the syntax *isn't* changing on an 
hourly basis.  The value constraints may change, and the system can 
be designed to respond to the flexibility needed to respond to the 
quick changes ... but do so without impacting something so 
fundamental as the syntax of the interchange document.  Just like the 
paper analogue.

I hope this helps.

. . . . . . . . . . Ken

--
Contact us for world-wide XML consulting & instructor-led training
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/x/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal