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: Fwd: [ubl-ndrsc] Instance constraint checking



>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