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 
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



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


Powered by eList eXpress LLC