Re: Here's why I use XML Schemas ... Why do you use XML Schemas?

At 2011-04-18 10:00 -0400, Costello, Roger L. wrote:
>I use XML Schemas to check that data meets the expectations and 
>constraints of my business.
>
>For example, my business supports these credit cards: MasterCard, 
>Visa, and American Express. My business expects purchase orders it 
>receives to use one of those credit cards. My business transmits 
>purchase requests using one of those credit cards. To express my 
>business expectation/constraint in a way that is 
>machine-processable, I created an XML Schema which enumerates the 
>supported credit cards:
>
>     <xs:simpleType name="CreditCards">
>         <xs:restriction base="xs:string">
>             <xs:enumeration value="MasterCard" />
>             <xs:enumeration value="Visa" />
>             <xs:enumeration value="American Express" />
>         </xs:restriction>
>     </xs:simpleType>
>
>Using that simpleType, these datum can be identified as not acceptable:
>
>      Diners Club
>      Hello World
>      delete * from *
>
>So, I use XML Schemas to ensure (as best I can) that my business 
>applications receive legitimate data and don't receive bad data (and 
>conversely, that my business applications transmit legitimate data 
>and not bad data).
>...
>Strong data typing helps me to ensure that my business applications 
>receive legitimate data and don't receive bad data (and conversely, 
>that my business applications transmit legitimate data and not bad data).

You say "business", and it is consistent with your example, so my 
answer focuses on business systems accepting XML documents.

Some real-world business constraints change too frequently to trap 
document constraints in a schema to reflect them.  And business 
constraints vary between trading partners ... another reason not to 
trap document constraints reflecting them in a schema.

I'm pretty sure we've had this discussion before, Roger.

>I create XML Schemas with strong data typing. I use XML Schemas to 
>ensure that inbound and outbound data meets my expectations and 
>business constraints.
>
>Why do you use XML Schemas?

In a business system I use a schema language (be it W3C Schema, 
RELAX-NG, DTD) only for structural and lexical constraints (where 
lexical constraints could be considered just structural constraints 
on a value:  a number, a string, a pattern).

I then layer on top of using the schema a separate process addressing 
value constraints using OASIS genericode and OASIS context/value association.

This is the model being implemented for OASIS Universal Business 
Language (UBL).

In your example, you've trapped three brands of credit card in the 
schema definition.  Your application supports all three, and, say, 
you have code that for each credit card company, uses that company's 
REST API for transactions.

Fine.  Took you months to develop all the code.  Took you weeks to go 
through the QA process of integrating the W3C Schema expression into, 
say, a JAXB interface to your program.  Your programmer has gone off 
on a well-deserved cruise vacation and is unavailable.

One day, at noon, MasterCard suspends your merchant account because 
of a discrepancy of some kind.  Transactions that morning went along 
just fine.  Now, after noon, you cannot accept MasterCard anymore 
until the discrepancy is resolved.

Are you really going to modify your W3C Schema, recompile your 
application, go through a complete QA process and be up and running 
to run your business supporting only two credit cards?

But, what if your program that supports all three credit cards has a 
front end of structural/lexical validation and value validation for 
instances to be processed?

Your programmer has created an environment that, based on file time 
stamps, recreates the "second pass value validation" whenever the CVA 
and/or genericode files change.  The process used for UBL creates an 
XSLT stylesheet from the CVA and genericode files (that process is 
publicly available from my web site developer resources).

So, at noon you get the news you cannot accept MasterCard for the 
time being.  You modify the genericode code list of acceptable 
cards.  You push the button and recreate the XSLT value validation 
pass.  You don't have to touch the schema, you don't have to 
recompile the application program that accepts MasterCard because the 
value validation will reject the input instance because that is no 
longer a valid value for processing.

The same rejection handling for a credit card value of "DinersClub" 
is then engaged for "MasterCard" and your system chugs along without 
interruption.

And this scenario could be applied on a per client basis as well.  If 
one client is trustworthy enough to accept cheques and another client 
is not, then each client can have CVA/genericode reflecting that 
trading partner's business relationship with you.  Your programmed 
application supports all possible combinations available to all 
customers, but just like the schema rejects instances with invalid 
structural/lexical content, the value validation pass rejects 
instances with invalid values.

As your real-time real-world business relationship changes with 
different trading partners, you just reflect the parameters of that 
relationship in different CVA/genericode combinations for 
each.  Whenever the relationship changes, you change the parameters 
of the value validation.

You don't have to change the structural constraints in the schema, so 
you don't have to incorporate a revised schema into all of your 
processes, which might impact those programs that have "compiled in" 
awareness of the schema, which involves expensive programming 
resources and quality assurance and all the overhead therein.

So, in summary, I think using W3C schema is fine in a real-world 
business application for constraining the structure of my data, both 
element structure and value structure (lexical constraints).  But it 
isn't acceptable to reflect differing (between trading partners) and 
changing (for the same trading partner) business parameters that 
happen on a different schedule, or on no schedule at all.

The schema is far too sensitive an artefact in which to reflect such 
dynamic aspects of a trading partner relationship in real-world 
business.  The impact of schema changes hits too may other aspects of 
the overall system.  No problem, of course, with static environments 
like publishing or data processing where constraints don't change on 
external stimuli.  I don't go through the additional layer of value 
constraints as separate from structural constraints in environments 
where value constraints are not expected to change.  Putting value 
constraints in a schema in those scenarios makes a lot of sense, and 
why bother adding the layer if you don't need the flexibility?  I'm 
not saying a schema language isn't a place to put both structural and 
value constraints in some scenarios.

It just doesn't make sense in a business scenario.

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

Received on Monday, 18 April 2011 14:52:39 UTC