OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: Fwd: [ubl-ndrsc] Instance constraint checking

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 


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...
>>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, 
>><!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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC