UBL Naming and Design Rules SC

Fwd: [ubl-ndrsc] Instance constraint checking

  • 1.  Fwd: [ubl-ndrsc] Instance constraint checking

    Posted 01-09-2002 11:12
    
    >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