[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Fwd: [ubl-ndrsc] Instance constraint checking
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> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC