[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
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]