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

["Burcham, Bill" <Bill_Burcham@stercomm.com>]

The example seems like it's actually trying to be two examples at once: 

a) the tax (abstract) type with two (concrete) subtypes -- PercentTax and
FlatRateTax
b) some type with 250 subtypes

The modeling approach for the two different cases may very well be
different.  I suggest if we want to talk about both (a) and (b) that we're
clear that they aren't necessarily solved by the same approach.

For the tax example (a), couldn't I handle this trivial modeling problem
with plain old XML schema using one of the "Variable Content Container"
approaches http://www.xfront.com/VariableContentContainers.pdf

In particular "Method 4: Implementing variable content containers using a
dangling type" describes how to create a variable content container
containing a simple type.

Is there some advantage to the schematron approach over "Method 4" for the
tax example?

For problem (b), can you give an example -- because I don't think tax fits
(with 250 subtypes).

-Bill


> -----Original Message-----
> From: Eve L. Maler [mailto:eve.maler@sun.com]
> Sent: Wednesday, January 09, 2002 12:09 PM
> To: ubl-ndrsc@lists.oasis-open.org
> 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
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>