[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-dev] Re: Test Assertions for UBL Calculation Model? Re: Re: [ubl-dev] Basic Invoice Exploration
Sorry, for that snippet to be meaningful BTW it needs a bit more of course e.g. ... <target>doc($invoice-instance)//cac:TaxTotal/cbc:TaxAmount</target> ... <predicate lg="xpath2">sum( ../cac:TaxSubtotal/cbc:TaxAmount )</predicate> ... I didn't check that the target xpath here is correct but it gives the idea There may be another way to do this (here the markup may be less stable) - just needs documenting separately to perhaps feed the test suite as test metadata (parameters and/or questionaire) or a full set of property-defining test assertions perhaps... <testAssertionSet> <header> ... <var name="invoice-instance">[some url or uri or the like to identify the instance as a category of target]</var> ... </header> <testAssertion> ... <target type="$invoice-instance">//cac:TaxTotal/cbc:TaxAmount</target> ... <predicate lg="xpath2">sum( ../cac:TaxSubtotal/cbc:TaxAmount )</predicate> ... </testAssertion> ... </testAssertionSet> Stephen D Green 2009/6/24 Stephen Green <stephen.green@documentengineeringservices.com>: > Hi Ken > > The WS-I-esque executable test assertion xpath profile from > the way it is looking doesn't include that 'eq' - it is implicit. > That makes the assertions easier to read and interpret and > most of all to execute. I guess the implicit 'eq' becomes part > of the xpath profile spec itself so when you say > > ... > <target>doc($invoice-instance)</target> > ... > <predicate lg="xpath2">sum( ../cac:TaxSubtotal/cbc:TaxAmount )</predicate> > ... > > the 'lg="xpath2"' binding attribute includes the 'eq' implictly by > it being defined as part of the profile spec semantics for 'xpath2' > code. A few other things like that would be defined in the xpath > profile spec too, like how test assertion variables are expanded > within the expressions where they are used. > > We are keen to standardise such a profile, following on from > the TAG TC work on the markup (which we think needs to be > standardised too, to provide a good foundation for the profile). > We haven't firmly decided which standards organisation yet. > I guess UBL can just get going with its own profile and convert > perhaps (for tool support sake, at least) later when the time is > right. That might provide feedback for TAG TC and what ever > ensues regarding XPath profile work. > > Glad you're getting into this. > > Best > > Steve > > Stephen D Green > > > > 2009/6/24 G. Ken Holman <gkholman@cranesoftwrights.com>: >> At 2009-06-23 21:36 +0100, Stephen Green wrote: >>> >>> I added to wiki what could be a possible start on which entities >>> need the calculation assertions >> >> I have taken your examples and I've proposed a pro-forma use of the wiki to >> express the needed test assertions: >> >> http://wiki.oasis-open.org/ubl/Example_Calculation_Models#proforma >> >> ... and fleshed it out with your first examples here: >> >> http://wiki.oasis-open.org/ubl/Example_Calculation_Models/Invoice_Tax_Total >> >>> I realise it's a little different to your proposed way forward Ken. >>> I'm more inclined to think the way to go is to set up a project >>> for assertions about the calculation model which feeds directly >>> into the UBL TC and its process for authoritative approval >>> rather than start with a more distant model like the OIO-UBL one >>> which might be seen as a customisation model rather than >>> official UBL TC one. >> >> One ramification of using an assertion (with true/false results) is that the >> expression doesn't really look like a calculation, though of course it >> incorporates the calculation. >> >> Whereas I originally had: >> >> sum( ../cac:TaxSubtotal/cbc:TaxAmount ) >> >> ... to make that into an assertion it has to read: >> >> . eq sum( ../cac:TaxSubtotal/cbc:TaxAmount ) >> >> Now that isn't a big change, and I can live with it, but it changes the >> "feel" of the document. >> >> I can live with it because as a programmer, if I see the test condition I >> can infer what I have to do to make the test evaluate to true. >> >> And, it means that if someone has a TA engine they could run their generated >> instances through the TA engine and get a report that they've met the >> conditions. >> >> When it comes time to write the HISC document, we'll have to explain the >> perspective of the calculation model documentation as one of "confirming the >> calculation model has been followed" rather than "the steps of calculation". >> >> Jaymuz (and others) ... do you feel that test assertions can effectively >> document what you need to implement in your systems? >> >> Stephen ... can you improve on the pro-forma and examples based on your >> previous work with test assertions? On the cover page I've assumed the >> expression language is XPath 2.0 and I've left the identification of the >> assertions to the step when we assemble them into our document. >> >> . . . . . . . . . . . Ken >> >> -- >> Crane Softwrights Ltd. http://www.CraneSoftwrights.com/u/ >> Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video >> Video lesson: http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18 >> Video overview: http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18 >> G. Ken Holman mailto:gkholman@CraneSoftwrights.com >> Male Cancer Awareness Nov'07 http://www.CraneSoftwrights.com/u/bc >> Legal business disclaimers: http://www.CraneSoftwrights.com/legal >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: ubl-dev-unsubscribe@lists.oasis-open.org >> For additional commands, e-mail: ubl-dev-help@lists.oasis-open.org >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]