[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
So I propose we go through the process of trying to make all the executable, xpath-expressible test assertions we can and use prose to express any other test assertions we need. Then we can maybe gradually replace more and more of the prose with executable expressions over time, until we are ready to think about going beyond draft stage. (Sounds quite Turing-esque) Then we will also need provenance/status/versioning so may I also suggest we make use of a scheme for putting this info into the testAssertion/@id - much as we do for namespaces in OASIS schemata - say using a urn or uri scheme to show status of the TAs (e.g. ':draft:', etc). There are two ways to consider - put the urn or uri into the @id of the testAssertionSet or into each testAssertion/@id. References can use chaining of id's like package names in Java or namespaces in dot NET Just saw Ken's response to previous posting so I'll check it out just after I post this. BTW a prose TA is simply signified by the 'lg' attribute so we need an execution engine to be able see when execution is appropriate and when human intervention/handling is required. Best Steve Stephen D Green 2009/6/24 Stephen Green <stephen.green@documentengineeringservices.com>: > Here's an example I just prepared (show two ways of doing the same thing > depending on how the execution mechanism, test context, etc works) > > <?xml version="1.0" encoding="UTF-8"?> > <testAssertionSet xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:noNamespaceSchemaLocation="TestAssertionMarkup-0-4/testAssertion-0-4.xsd"> > <testAssertion id="ta-example-001"> > <var name="ubl-invoice-2-0-schema">http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/common/UBL-CommonAggregateComponents-2.0.xsd</var> > <normativeSource><refSourceItem>fn:doc($ubl-invoice-2-0-schema)/xsd:schema/xsd:complexType[64]/xsd:sequence[1]/xsd:element[1]/xsd:annotation[1]/xsd:documentation[1]/ccts:Component[1]/ccts:Definition[1]</refSourceItem></normativeSource> > <target>/default:Invoice/cac:LegalMonetaryTotal[1]/cbc:LineExtensionAmount[1]</target> > <prerequisite>/default:Invoice/cac:InvoiceLine[1]/cbc:LineExtensionAmount[1]</prerequisite> > <predicate>sum(/default:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount)</predicate> > <prescriptionLevel>mandatory</prescriptionLevel> > </testAssertion> > <!-- <testAssertion id="ta-example-001"> > <var name="ubl-invoice-2-0-schema">http://docs.oasis-open.org/ubl/os-UBL-2.0/xsd/common/UBL-CommonAggregateComponents-2.0.xsd</var> > <var name="ubl-invoice-2-0-instance">.</var> > <normativeSource> > <refSourceItem>fn:doc($ubl-invoice-2-0-schema)/xsd:schema/xsd:complexType[64]/xsd:sequence[1]/xsd:element[1]/xsd:annotation[1]/xsd:documentation[1]/ccts:Component[1]/ccts:Definition[1]</refSourceItem> > </normativeSource> > <target>fn:doc($ubl-invoice-2-0-instance)/default:Invoice/cac:LegalMonetaryTotal[1]/cbc:LineExtensionAmount[1]</target> > <prerequisite>fn:doc($ubl-invoice-2-0-instance)/default:Invoice/cac:InvoiceLine[1]/cbc:LineExtensionAmount[1]</prerequisite> > <predicate>sum(fn:doc($ubl-invoice-2-0-instance)/default:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount)</predicate> > <prescriptionLevel>preferred</prescriptionLevel> > </testAssertion> --> > </testAssertionSet> > > Best regards > > Steve > > Stephen D Green > > > > 2009/6/24 Stephen Green <stephen.green@documentengineeringservices.com>: >> 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]