Re: [ubl-dev] Re: Test Assertions for UBL Calculation Model? Re: Re: [ubl-dev] Basic Invoice Exploration

[Stephen Green <stephen.green@documentengineeringservices.com>]

OK, Ken, point about the wiki and the markup taken.
I do think we should start with making marked-up TAs
and generate content for the wiki - just need a simple
stylesheet. A bit like you do for UBL specs with docbook
but in this case there is the bonus of potential use in
an actual test suite - that way the test suite has the
normative (or at least authoritative/approved) TAs to
work with and a human can see why a test might have
failed and how to change the target implementation
(in this case the document, mainly, or calculation
logic behind it). Where we put the markup is another
matter. Of course editing the wiki content directly is
fine as a precursor to working out the markup too. The
wiki need not all be XPath if folk find that too demanding
but someone needs to try to convert directly edited
material on the wiki into markup and perhaps then post
a generated output from that back to the wiki (or to a
separate document instead/as well). Lots of work of
course but I think a lot can be done with only a few key
assertions and the rest might be less essential.

Stephen D Green



2009/6/24 G. Ken Holman <gkholman@cranesoftwrights.com>:
> At 2009-06-24 15:33 +0100, Stephen Green wrote:
>>
>> 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)
>
> Thanks for posting that here for discussion.  I have a few observations to
> make about it.
>
>> <?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>
>
> There is no "default:" namespace.  The default namespace is a mechanism by
> which the namespace URI is ascribed to the element name without the use of a
> prefix.  I believe where you've used "/default:" we should be using "/in:"
> as I've documented in:
>
>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models#ns
>
>>
>>
>> <prerequisite>/default:Invoice/cac:InvoiceLine[1]/cbc:LineExtensionAmount[1]</prerequisite>
>>
>>
>> <predicate>sum(/default:Invoice/cac:InvoiceLine/cbc:LineExtensionAmount)</predicate>
>>        <prescriptionLevel>mandatory</prescriptionLevel>
>
> I note (based on your earlier post) the absence of the ". eq " part of the
> expression.  As I understand it, that would be implied by a particular
> binding.
>
>>    </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>
>
> It is unclear to me why the second one is "preferred" and the first one is
> "mandatory".  Can you help me with that?
>
> But a major point I would like to make is that I don't believe we need TA
> markup in the wiki.  I see TA markup being synthesized from the HISC
> document we create that captures the information from the wiki that is
> captured from users.
>
> Personally I would the wiki to be comprised of simple lists that anyone can
> read.  From what I can tell, there is enough information in:
>
>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models/Invoice_Tax_Total
>
> ... to construct your example instance above.  The identifiers can be
> synthesized at the time we generate the assertions.  If we need to express a
> dependency in the wiki then we can assign abstract identifiers there and
> replace them with identifiers at the synthesis stage, or preserve them if
> they look meaningful.  I just threw in "mandatory" into my example until I
> better understand the distinction.
>
> I would like the HISC document to be human-readable ... then I can write a
> stylesheet to synthesize the assertion markup based on whatever the
> vocabulary is at the time we are ready to create some executable code.
>  Please let me know if you think there is any information missing in the
> wiki that would be needed in the assertion.  This will allow anyone
> interested in implementing the example models to use any technology they
> wish ... for demonstrative purposes the HISC can use OASIS Test Assertions.
>
> I would be interested to hear the opinion of others if we should put markup
> in the wiki or just the nested lists.  And, Stephen, you are welcome to
> convince me otherwise ... I don't want my opinion here to be treated as
> immutable.  If you do agree with me, then you can take out the assertion
> markup from:
>
>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models
>
> Members of UBL-Dev are a main target audience for this work, hence it makes
> sense to discuss your needs here on the UBL-Dev list.  I look forward to
> your feedback.
>
> . . . . . . . . . . . . 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
>
>