[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