Re: [tag] Referencing external test assertions

[Stephen Green <stephengreenubl@gmail.com>]

I guess one way is with a variable

<var name="doc1"
lg="xpath20">doc("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-%20draft-0-61.xml";)</var>
...
<testAssertionRef>$doc1."Test Assertions for Universal Business
Language v2 Invoice Calculation
Model".invoice-calculation-model-001.INVTAX001</testAssertionRef>

but what about the testAssertionRef here - it has to combine two
syntaxes - XPath for the variable with our own point notation for
the IDs.

A pure XPath way would be to not use the point notation but some
XPath equivalent:

something like

<testAssertionRef
lg="xpath20">$doc1//*[local-name(.)='testAssertionSet']/@id='invoice-calculation-model-001'/*[local-name(.)='testAssertion']/@id='INVTAX001'</testAssertionRef>

or even, without the variable

<testAssertionRef
lg="xpath20">doc("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-%20draft-0-61.xml";)//*[local-name(.)='testAssertionSet']/@id='invoice-calculation-model-001'/*[local-name(.)='testAssertion']/@id='INVTAX001'</testAssertionRef>

but it's no where near as neat as the point-separated ref notation.

If we include the point notation built in to the markup (not everyone
is familiar with XPath nor should have to be), like packages notation
in Java, then maybe we need a special reference element (a bit like
a special variable element):

<ref url='http://www.oasis-open.org/committees/download.php/34247/ubl-ta-%20draft-0-61.xml'
name='ref1'/>

or

<ref name='ref1'>http://www.oasis-open.org/committees/download.php/34247/ubl-ta-%20draft-0-61.xml</ref>

(the latter assuming more, eg that the ref is navigable using usual methods like
trying as a filepath/filename then trying as a url or that a
filepath/filename will
always be presented as a file:/// url which leaves less scope for
relative paths)

Then the TA ref is something like:

<testAssertionRef>$ref1."Test Assertions for Universal Business
Language v2 Invoice Calculation
Model".invoice-calculation-model-001.INVTAX001</testAssertionRef>

and we might want to have a dot dot notation (like the '//' in XPath) to
show a more indefinite child relationship (any child or granchild) to
avoid something like that cumbersome first ID in my example

<testAssertionRef>$ref1..invoice-calculation-model-001.INVTAX001</testAssertionRef>

There are weaknesses

1. having to use BNF or the like to define this notation formally
2. having to have reservced characters e.g. '$' and '.' (and '..') which
    realistically could appear in the IDs

2. could be gotten around specifying an escape character like '\'

1. may just be essential extra work in the spec - anyone any good at BNF? :-)


XPath binding profile tools would just need to support both
methods if the latter point notation is part of the TAML spec,
I guess. That presumably applies to any profile and may be
quite an overhead. Quite powerful to have it though.

---
Stephen D Green




2009/9/18 Kevin Looney <Kevin.T.Looney@sun.com>:
> Hi Stephen,
>
>   This is a good question to bring up.
>
>    I'm not aware of any rules here, but it seems like a 'convention' (or
> guideline) would go a long way for TA organization or Tool processing.  This
> issue seems fairly similar to TA naming, which we also gave
> guidelines/conventions - so I'm guessing we should treat this similarly.
>
> The example you gave seems logical (concentric owning sets, separated by
> dots). Perhaps one of the identifiers (probably the outermost one) needs to
> be a symbolic representation of the Spec Name / version / revision / date.
>  Then again, we may wish to refer to TAs from specs, where the TAs live over
> multiple versions (so specifying version / revision / date is not
> important).
>
> Regarding 'import',  this may be important for a schema.  For the spec
> itself, it seems like a well formed specification should describe (in some
> sort of references section) where it refers to behavior / conformance from
> another spec.  Likewise, an analysis should probably describe some sort of
> reference too.
>
> Just some thoughts off the top of my head.
> Kevin L
>
>
> Regarding
> Stephen Green wrote:
>>
>> Re: Referencing external test assertions
>>
>> Questions:
>>
>> Given that I have a set of TAs in an upper level TA Set
>> in an instance file/document, how would I apply a set
>> of prerequisites to these TAs as a whole or individually
>> using the Test Assertion Markup Language? Is there
>> any special construct or best practice I would need to
>> clarify unambiguously that the TAs (referenced by their
>> IDs and the TA Set IDs e.g. 'TASet1.TASet2.ta0001')
>> are to be found in a certain file? Do we need some kind
>> of construct in the referring instance like an 'include' or
>> 'import' statement/element? How is this done in other
>> TA methodologies/languages? Would it be something
>> new/untested for TAML if we added it? Could tools handle
>> such a construct properly? What issues might there be?
>>
>> Best regards
>> ---
>> Stephen D Green
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>
>