UBL Naming and Design Rules SC

 View Only

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

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

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