Re: [tag] Referencing external test assertions

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

perhaps <testAssertionRef>
should have a name or ID of its own
so that we can declare one in a
TA Set, give it an ID if it didn't have
one, then, like with a catalog, use
this ID to reference it in TA sets
within that TA set, for example, to
avoid repetition.

 <testAssertionRef id="...">    <!-- or name="..." -->
  <resource url="..." filename=".." fileID="...">
    <taSetId value="..">
      <taSetId value="..">
        <taId lineNumber="..."/>
      </taSetId>
    </taSetId>
  </document>
 </testAssertionRef>


---
Stephen D Green




2009/9/18 Stephen Green <stephen.green@documentengineeringservices.com>:
> Another way
>
> <testAssertionRef>
>  <resource url="..." filename=".." fileID="...">
>    <taSetId value="..">
>      <taSetId value="..">
>        <taId>..</taId>
>      </taSetId>
>    </taSetId>
>  </document>
> </testAssertionRef>
>
> This has the advantage of us not needing any BNF, just schema.
>
> Metadata could included as further attributes (there are various
> places to add these - 'resource' or 'testAssertionRef' or 'taSetId'
> or 'taId')
>
> Questions: What happens if the TAs are in a database?
> Does that mean the database has to be REST-enabled
> or equivalent? What if it is a paper document? etc
> Maybe this can be handled with further attributes on 'resource':
>
> <testAssertionRef>
>  <resource url="..." filename=".." fileID="..." sql="..." ref="..." date="...">
>    <taSetId value="..">
>      <taSetId value="..">
>        <taId>..</taId>
>      </taSetId>
>    </taSetId>
>  </document>
> </testAssertionRef>
>
> Would this mechanism handle TAs in formats other
> than TAML? e.g javadocs? HTML? WS-I's XML? macros?
> Schematron? UML/CDL? XML Schema even? ANSI prose?
> Predict? Docbook? DITA? PDF? ODF? etc As long as
> each TA has a unique ID and the document as a whole
> can be uniquely identified then I guess so. Not sure TAs
> in source code, etc have identifiers though - line numbers
> may be needed. How would we represent a line number?
> As an attribute on 'taId' perhaps so perhaps more appropriate
> is:
>
> ...
>      <taSetId value="..">
>        <taId value=".." lineNumber="..">
>      </taSetId>
> ...
>
>
> ---
> Stephen D Green
>
>
>
>
> 2009/9/18 Stephen Green <stephengreenubl@gmail.com>:
>> Plus we could give our notation a language code (like
>> we could give XPath 2.0 the 'xpath2' code) so it can
>> be added to the testAssertionRef's @lg attribute
>>
>> e.g. 'ta'
>> <testAssertionRef
>> lg='ta'>("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-draft-0-61.xml";)."Test
>>  Assertions for Universal Business Language v2 Invoice Calculation
>>  Model".invoice-calculation-model-001.INVTAX001</testAssertionRef>
>>
>> this would distinguish it from any XPath equivalent
>>
>> <testAssertionRef
>> lg="xpath20">doc("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-draft-0-61.xml";)//*[local-name(.)='testAssertionSet']/@id='invoice-calculation-model-001'/*[local-name(.)='testAssertion']/@id='INVTAX001'</testAssertionRef>
>>
>> or (aside from namespace issues)
>>
>> <testAssertionRef
>> lg="xpath20">doc("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-draft-0-61.xml";)//testAssertionSet/@id='invoice-calculation-model-001'/testAssertion/@id='INVTAX001'</testAssertionRef>
>>
>> or (with the namespace prefixed and resolved somehow)
>>
>> <testAssertionRef
>> lg="xpath20">doc("http://www.oasis-open.org/committees/download.php/34247/ubl-ta-draft-0-61.xml";)//tag:testAssertionSet/@id='invoice-calculation-model-001'/tag:testAssertion/@id='INVTAX001'</testAssertionRef>
>>
>>
>> (though I'm not even sure the XPath one is valid in place of
>> an identifier since it resolves to a node rather than a location/ID
>> - something an XPath profile would perhaps need to sort out
>> if it allowed this expression for the TA ref)
>>
>>
>> ---
>> Stephen D Green
>>
>>
>>
>>
>> 2009/9/18 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
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>