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

["Stephen Green" <stephen.green@bristol.gov.uk>]

So we could improve these rules/assertions in two steps:

Step A. work out more precisely the conditions in which they
are sufficient for a blanket conformance clause (i.e. with
minimal further qualification in such a clause/conformance profile)

  e.g. we could say one condition/prerequisite is that
          there is no PrepaidAmount in the invoice

Step B. add further rules to apply when the conditions are
*NOT* met 
  
   e.g. what is a proper/useful assertion/assertion set when 
        there IS a PrepaidAmount in the invoice

Does this sound reasonable? 
And given this approach are there any of the TAs that seem to be
useless
or misleading? (I can't really say 'false')

Best regards

Stephen D Green

>>> Stephen Green <stephengreenubl@gmail.com> 18/09/09 14:00 >>>
Sorry for this being in separate emails (typing while I think,
unsure what time I'll have left to spend on this jsut now):

What my TAs lack is a conformance clause with which they
would normally be associated.

There is an interesting fact about test assertions: they are
not invalid just because they aren't always true. The assertions
are neither valid nor invalid. They are simply asserted and the
judgement about the cases where they are invalid for a 'target'
(or effectively what will be a candidate 'system under test', SUT)
and what that means is separate to the statement of the test
assertions. So my assertions are neither valid/true nor invalid
/false. They just are. :-) A bit like the semantic web :-) Ontologies
are made of statements without being true or false - they just are.

So the TAs exist as useful statements which can be incorporated
into artefacts to help with testing and validation, etc but which
have to be qualified in context (usually with other test assertions
with which they are chained - either is prerequisites or predicates
or qualificatins of targets, eg using variables - or with a
conformance
clause). So these TAs I would agrue are valid, as much as any TA
is valid. They, like any TA, need to exist in context which qualifies
them. All very philosophical. A bit like Schematron. They tell me
this all makes more sense if you are of oriental origin, less so if
you are greek-latin, western origin and mindset.

So it can always be the case that the TAs can be further and further
qualified and resused/qualified in different ways for different
purposes.

What we lack is the conformance profiles which close them off
with a conformance profile and make them concrete for testing.
Or interoperability profiles, etc. So in effect 'just add subset' (and
probable more TAs).

How much of this do we want to do?
---
Stephen D Green




2009/9/18 Stephen Green <stephengreenubl@gmail.com>:
> I guess what I was going to say about approach 2. below
> was that we could write a rule to cater for all of the UBL 2
> standard entities relating to the calculations of totals and
> leave it to customisers to change these macroscopic
> calculations. I think the danger/side effect that this would
> add lots of complexity is too costly to warrant the benefit.
> I'd prefer the 80:20 approach (although some might argue
> that the whole of UBL is already 80:20, though I don't
> agree): cater for entities participating in 80% of calculations
> (an arbitrary general knowledge judgment I admit) and make
> exceptional extra assertions to cover the corner cases. So
> here we would say something in the TAs to the effect that
> rules in TA Set invoice-total-001 apply UNLESS a) you have
> PrepaidAmount in the invoice or b) ... or c) ...  This could be
> done with a blanket prerequisite for that Test Assertion Set
> (id = invoice-total-001). Another way is to use the existing
> TAs (the rules below) and match them to a conformance
> profile whose conformance clause includes the assertion
> that the invoice does not include a PrepaidAmount (in effect
> a subset profile).
>
> ---
> Stephen D Green
>
>
>
>
> 2009/9/18 Stephen Green <stephengreenubl@gmail.com>:
>> I've been thinking a bit about this:
>>
>> If we say a calculation is A = B + C + D - E
>>
>> then someone has a customisation which subsets out D
>>
>> we could do several things
>>
>> 1. let them rewrite the calculation (e.g. without D in it, though
it
>> may mean a more complex change than that)
>>
>> 2. leave it as it is
>>
>> 3. write into the calculation test assertion logic more
prerequisites
>> e.g. to say "if exists B and exists C and exists D and exists E
>> or a more thorough way would be to split up the logic
>> "if exists B and not exists C, D, E then A = B..."
>> "if exists B and not exists C, D, E then A = {f(B)}"
>> "if exists B, C and not exists D, E then A = {f(B, C)}"
>> "if exists B, C, D and not exists E then A = {f(B, C, E)}"
>> etc
>>
>> I think 3. is what is really needed but it means a lot more work.
>> In practice there is not too much work because often some of
>> A, B, C, D, etc are mandatory in the standard schema.
>>
>> My approach has been to make assumptions some of which
>> I have to add as further prerequisites. I guess I've been assuming
>> something like the Small Business Subset and letting other subset
>> people write their own rules - but I need to look into this and
make
>> it explicit by enhancing the test assertion prerequisite(s),
perhaps.
>> I guess even that is useful though because most will be using
>> something like the SBS and mainly concerned with the logic found
>> in those most-important elements. If you are using other totals
like
>> PrepaidAmount then you need to build that into the calculation
>> model you use. Perhaps suffice it to say, if you start with the
model
>> I've provided so far you 1. have to take it as is  and 2. need to
assess
>> how appropriate or otherwise it is in your situation. I do think it
fits
>> with the original intentions of the designers of UBL 1 whose design
>> was mainly carried over as-is (I think) into UBL 2 (with
additions).
>> The UBL 1 ubset was hardly affected by UBL 2 (in fact we even
>> gave up the considerable effort of getting the 2.0 SBS through to
>> official committee spec stage because UBL 1 SBS mainly did the
>> job.
>>
>>
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2009/9/18 Stephen Green <stephen.green@bristol.gov.uk>:
>>> Thanks Oriol for looking at these in detail. I'll try to respond
>>> in detail a bit later but in the meantime it kind of vindicates
>>> the TC decision to not mandate just one calculation model as
>>> people may need different models if their subsets include
>>> different elements. Maybe what I have defined is a broader
>>> model than you'd like. Maybe it does have errors though so I
>>> will check. Maybe, too, we can have an agreed ubl-dev model
>>> that would benefit a wide base of implementations.
>>>
>>> Regarding the rule/test assertion INVTOT002 it does kind of
>>> show that the formal expression using the combination of
>>> XPath and Test Assertion Markup Language (or equivalent)
>>> 1. generally loses something in 'translation' into prose no
>>> matter how much you try (by " invoice 'AllowanceCharge' "
>>> I meant AllowanceCharge at document level)
>>> 2. gives the expressiveness needed to state unambiguously
>>> what is meant but that this isn't all that 'human-readable' so
>>> prose may be needed too.
>>> I would recommend referring to the XPath and the full logic
>>> of the TA to get the actual, normative meaning rather than
>>> the interpretation.
>>>
>>> Best regards
>>>
>>> Steve
>>>
>>>>>> Oriol Bausà <ORIOL@INVINET.ORG> 18/09/09 09:19 >>>
>>> Hi Stephen,
>>>
>>> Some comments on the rules,
>>>
>>> El 17/09/2009, a las 14:54, Stephen Green escribió:
>>>>
>>>>
>>>> Test Assertion ID: invoice-total-001.INVTOT002
>>>>
>>>> Rule: given that there is only one currency used in the invoice
and
>>>> that there is at least one invoice line with a line extension
>>> amount,
>>>> the 'TaxExclusiveAmount' in the invoice 'LegalMonetaryTotal' is
>>>> equal to the sum of the 'LineExtensionAmount's in all of the
invoice
>>>> lines plus the sum of the invoice 'AllowanceCharge' charges minus
>>>> the sum of the invoice 'AllowanceCharge' allowances
>>>
>>> There are AllowanceCharges at header and line level, which ones
are
>>> you referring to?
>>>
>>>>
>>>> Test Assertion ID: invoice-total-001.INVTOT003
>>>>
>>>> Rule: given that there is only one currency used in the invoice
and
>>>> that there is at least one invoice line with a line extension
>>> amount,
>>>> the 'AllowanceTotalAmount' in the invoice 'LegalMonetaryTotal' is
>>>> equal to the the sum of the invoice 'AllowanceCharge' allowances
>>>> minus the sum of the invoice 'AllowanceCharge' charges
>>>>
>>>
>>> Don't agree. There is a ChargeTotalAmount in the
LegalMonetaryTotal.
>>> AllowanceTotalAmount should be the total of allowances, and
>>> ChargeTotalAmount the total of charges.
>>>
>>>> Test Assertion ID: invoice-total-001.INVTOT004
>>>>
>>>> Rule: given that there is only one currency used in the invoice
and
>>>> that there is at least one invoice line with a line extension
>>> amount,
>>>> in the invoice 'LegalMonetaryTotal' the 'LineExtensionAmount' is
>>>> equal to the 'TaxExclusiveAmount' plus the 'AllowanceTotalAmount'
>>>>
>>>
>>> I do not agree. The LineExtensionAmount equals the sum of
>>> LineExtensionAmounts at line level, as per your first rule.
>>>
>>>> Test Assertion ID: invoice-total-002.INVTOT005
>>>>
>>>> Rule: [given that all test assertions in the test assertion set
>>>> 'invoice-total-001' are passed],
>>>> the 'PayableAmount' in the invoice 'LegalMonetaryTotal' is equal
to
>>>> the TaxExclusiveAmount (in the invoice 'LegalMonetaryTotal')
>>>> plus the sum of the invoice total tax amounts (at invoice
document
>>>> level)
>>>>
>>>
>>> I'd say that TaxInclusiveAmount equals TaxExclusiveAmount plus the
>>> sum of the invoice total tax amounts.
>>>
>>> And PayableAmount is TaxInclusiveAmount minus the PrepaidAmount
>>>
>>> Regards, Oriol
>>>
>>>>
>>>> These are expressed using XPath in the test assertions document:
>>>>
>>>> http://www.oasis-open.org/committees/download.php/34247/ubl-ta- 
>>>> draft-0-61.xml
>>>>
>>>> I'm short on time but hope to be able to add these to the UBL
wiki
>>>> if there aren't objections.
>>>>
>>>> Best regards
>>>> ---
>>>> Stephen D Green
>>>>
>>>>
>>>>
>>>>
>>>> 2009/6/25 Stephen Green
>>>> <stephen.green@documentengineeringservices.com>:
>>>>> OK, now on [pause].
>>>>>
>>>>> I'll come back to this thread when I've got some test assertions
>>>>> written
>>>>> for the UBL calculation model.
>>>>>
>>>>> Best
>>>>>
>>>>>
>>>>> Stephen D Green
>>>>>
>>>>>
>>>>>
>>>>> 2009/6/24 Stephen Green
>>>>> <stephen.green@documentengineeringservices.com>:
>>>>>> The other advantage of using XPath ...
>>>>>>
>>>>>> [ like one starting
>>> doc("http://docs.oasis-open.org/ubl/...";)/...
>>>>>> to say something about the
>>>>>> schema (e.g. to extract a dictionary entry name if you really
>>>>>> need one)
>>>>>> or doc($instance)/Invoice/... to assert something about the
>>> invoice
>>>>>> (where another reference
>>>>>> defines $instance), e.g. using a variable assignment element of
>>> the
>>>>>> xpath-profile test assertion ]
>>>>>>
>>>>>> ... is that you can make the assertion(s) executable. You can
>>>>>> perhaps
>>>>>> convert to Schematron
>>>>>> for individual assertions or if you want to chain the
assertions
>>>>>> (make
>>>>>> one dependant on the
>>>>>> outcome of testing an invoice according to another) you can
>>>>>> (eventually) use a test assertion
>>>>>> xpath profile execution engine. For the latter you may need to
>>> wait
>>>>>> for tools to be in production
>>>>>> or write your own but WS-I is doing the latter quite
successfully
>>>
>>>>>> and
>>>>>> I hope there will be tools
>>>>>> soon, perhaps some free ones.
>>>>>>
>>>>>> The Balisage 2009 XML conference will feature a presentation on
>>> this
>>>>>> by Jacques Durand of
>>>>>> Fujitsu US / WS-I / OASIS (TAG Chair, TAB, etc) which should be
>>>>>> excellent (plus Ken and I
>>>>>> both get a mention!).
>>>>>>
>>>>>> Stephen D Green
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2009/6/24 G. Ken Holman <gkholman@cranesoftwrights.com>:
>>>>>>> At 2009-06-24 19:36 +1000, jaymuz@optusnet.com.au wrote:
>>>>>>>>
>>>>>>>> Sorry to jump in gents but I was looking to build this myself
>>>>>>>> however you
>>>>>>>> gentleman know your way around these datasets better than I
do
>>>>>>>> and I am
>>>>>>>> hoping you may already have same.
>>>>>>>>
>>>>>>>> Do we have a list of BBIE's that may play a role in
calculating
>>>
>>>>>>>> the
>>>>>>>> balance of an amount in an invoice?
>>>>>>>
>>>>>>> You can see that Stephen and I have started here:
>>>>>>>
>>>>>>>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models/ 
>>>>>>> Invoice_Tax_Total
>>>>>>>
>>>>>>> ... where you can see we are using "nsprefix:UBLName" and
>>>>>>> definition,
>>>>>>> assuming a documentary set (not required set) of namespace
>>>>>>> prefixes listed
>>>>>>> here:
>>>>>>>
>>>>>>>  http://wiki.oasis-open.org/ubl/Example_Calculation_Models#ns 
>>>>>>>
>>>>>>>> I am talking all BBIE's that could form part of a
calculation.
>>>>>>>>
>>>>>>>> This would include a price in a catelogue that may transfer
to
>>>>>>>> an order.
>>>>>>>>
>>>>>>>> This would not include the address of a supplier.
>>>>>>>>
>>>>>>>> A list that would be useful would be:
>>>>>>>>
>>>>>>>> UBL Name | Object Class | Property Term | Data Type |
Definition
>>>>>>>
>>>>>>> Given that "nsprefix:UBLName" combination will uniquely find
the
>>>
>>>>>>> other
>>>>>>> information, and that applications will use "nsprefix:UBLName"
>>>>>>> for access to
>>>>>>> the information from programs or from stylesheets, I suspect
our
>>>
>>>>>>> level of
>>>>>>> detail is sufficient.
>>>>>>>
>>>>>>> One drawback to your proposed list is that it doesn't show
>>>>>>> context (many UBL
>>>>>>> business entities are used in multiple contexts), so I'm
>>>>>>> proposing an XPath
>>>>>>> pattern address to the item in question and then a relative
>>>>>>> XPath address to
>>>>>>> the components on which it is based.  The information you want
>>>>>>> can be
>>>>>>> derived unambiguously from the "nsprefix:UBLName" components
>>>>>>> used in the
>>>>>>> XPath addresses.
>>>>>>>
>>>>>>> For example, consider the common library entry:
>>>>>>>
>>>>>>>  TaxTotal | Tax Total. Tax Amount. Amount | The total tax
amount
>>>
>>>>>>> for ...
>>>>>>>
>>>>>>> This has different contexts just in our first examples:
>>>>>>>
>>>>>>>  /in:Invoice/cac:TaxTotal/cbc:TaxAmount
>>>>>>>  /in:Invoice/cac:InvoiceLine/cac:TaxTotal/cbc:TaxAmount
>>>>>>>
>>>>>>> ... so your level of granularity would not distinguish these
two
>>>
>>>>>>> different
>>>>>>> contexts.
>>>>>>>
>>>>>>>> If not I will try and build one myself.
>>>>>>>
>>>>>>> It would help if you could join the committee and contribute
to
>>>>>>> the work of
>>>>>>> the HISC.  If not, then submitting your contributions through
>>>>>>> the official
>>>>>>> TC comment page is the way to have the committee formally
>>>>>>> consider your
>>>>>>> input:
>>>>>>>
>>>>>>>  http://www.oasis-open.org/committees/comments/form.php? 
>>>>>>> wg_abbrev=ubl
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> . . . . . . . . . . . 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 
>>>
>>>>>>>
>>>>>>>
>>>>>>>

______________________________________________________________________
'Do it online' with our growing range of online services - http://www.bristol.gov.uk/services 

Sign-up for our email bulletin giving news, have-your-say and event information at: http://www.bristol.gov.uk/newsdirect 

View webcasts of Council meetings at http://www.bristol.gov.uk/webcast