I think this is a useful example. As I recall, we were trying to home in
on the rationale for using something like Schematron as a secondary
validation device, and this does the trick. We'll have to put this into
our use case template eventually... That's something we can work on at the
F2F.
Eve
At 11:09 AM 1/9/02 -0500, Eve L. Maler wrote:
>>From: "Gregory, Arofan" <arofan.gregory@commerceone.com>
>>To: "Maler, Eve" <eve.maler@commerceone.com>
>>Subject: [ubl-ndrsc] Instance constraint checking
>>Date: Wed, 9 Jan 2002 03:48:21 -0800
>>X-Mailer: Internet Mail Service (5.5.2653.19)
>>
>>I forget who I was supposed to send this to, so I'm sending it to you...
>>
>>I hope this is the right example...
>>
>>Cheers,
>>
>>Arofan
>>____________________________
>>
>>Instance Constraint Checking
>>____________________________
>>
>>XML Schema languages such as XSDL allow a single "axis" of validation to
>>be applied to an instance, requiring certain fields to be required or
>>optional. However, it is often the case that to simplify structure,
>>fields are made optional that are in reality required, depending on the
>>values of other fields.
>>
>>Simple Example:
>>
>>I have a structure carrying tax information, involving a required field
>>"TaxType" that describes the tax as a flat rate or as a percentage. I
>>then have two optional fields, one containing a number that is an amount
>>("TaxAmount") to be used if the tax is a flat rate, and another that
>>contains the percentage ("TaxPercentage"), to be used if the tax is
>>expressed as a percentage.
>>
>>Although either TaxPercentage or TaxAmount is required - and I can even
>>express this in schema - I cannot easily express the fact that they are
>>tied to specific values in the TaxType field.
>>
>>Note that it is possible to come up with a structure that would look like:
>>
>><!element Tax ((PercentTaxType, TaxAmount) | (FlatRateTaxType,
>>TaxPercentage))>
>><!element PercentTaxType EMPTY>
>><!element FlatRateTaxType EMPTY>
>><!element TaxAmount (#PCDATA)>
>><!element TaxPercentage (#PCDATA)>
>>
>>However, when you extend the number of combinations, which is the case in
>>reality, you will end up with a huge and unweildy structure. If I had 250
>>choice in my tax-type list, rather than 2, and each of these could be
>>used with either TaxAmount, TaxPercentage, or both (or possibly some
>>other similar structure), suddenly I have a big problem with
>>combinatorics. Typically - as was done in xCBL - you simply document the
>>dependencies and rely on the applications to get it right, since the
>>simplicity of the structure is more important than the use of the parser
>>for this type of validation.
--
Eve Maler +1 781 442 3190
Sun Microsystems XML Technology Center eve.maler @ sun.com