Re: [tag] Referencing external test assertions

[Stephen Green <stephengreenubl@gmail.com>]

Afterthought: Instead of escaping '.' and '$' in any filenames,
filepaths or URLs
(I'm not sure '$' is allowed anyway so it might just be '.' we need to consider)
they could be wrapped in quotes (as with spaces, perhaps) so that favours the
<ref name='ref1'>url | filename | filepath + filename</ref> approach which does
not need to use its own quotes too.

But given that there is maybe a third design - just allow the point notation to
include the filepath/url as the first part (before the first point)
wrapped, say,
in its own quotes

<testAssertionRef>"http://www.oasis-open.org/committees/download.php/34247/ubl-ta-%20draft-0-61.xml"."Test
Assertions for Universal Business Language v2 Invoice Calculation
Model".invoice-calculation-model-001.INVTAX001</testAssertionRef>

This avoids the need for any extra elements in the TA markup. It has
disadvantages
of course, like verbosity and possible duplication. Or define a
separate way to wrap
the first filename/url part

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

Best regards

---
Stephen D Green




2009/9/18 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
>>>
>>
>>
>