atom feed16 messages in org.oasis-open.lists.tagRe: [tag] Referencing external test a...
FromSent OnAttachments
Stephen GreenSep 18, 2009 7:30 am 
Kevin LooneySep 18, 2009 8:02 am 
Stephen GreenSep 18, 2009 8:34 am 
Stephen GreenSep 18, 2009 8:44 am 
Stephen GreenSep 18, 2009 8:55 am 
Stephen GreenSep 18, 2009 10:19 am 
Stephen GreenSep 18, 2009 10:23 am 
Stephen GreenSep 18, 2009 10:56 am 
Stephen GreenSep 18, 2009 12:13 pm 
Stephen GreenSep 18, 2009 2:42 pm 
Stephen GreenSep 19, 2009 3:35 am 
Stephen GreenSep 19, 2009 3:43 am 
Jacques R. DurandSep 28, 2009 4:55 pm 
Stephen GreenSep 29, 2009 1:31 am 
Stephen GreenSep 30, 2009 2:00 pm 
Stephen GreenSep 30, 2009 2:43 pm 
Subject:Re: [tag] Referencing external test assertions
From:Stephen Green (step@documentengineeringservices.com)
Date:Sep 18, 2009 10:23:20 am
List:org.oasis-open.lists.tag

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>

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> ...

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)

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

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.

2009/9/18 Kevin Looney <Kevi@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