OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tag] Referencing external test assertions


Another attribute to carry database connection information?
Is there a standard for this, eg DSN, LDAP. I suppose
LDAP is like a URL but DSN might be a filename. Do we
need some special database attributes? Of course there
is the anyAtttribute extension point so custom attributes
can be added but this doesn't promote interoperability or
longevity.
---
Stephen D Green




2009/9/18 Stephen Green <stephen.green@documentengineeringservices.com>:
> Adding, like Kevin says, metadata to identify a specific
> version and revision and date plus we may need a codelist
> of known types of format (so we can automate getting the
> test assertion if possible):
>
>  <testAssertionRef id="...">    <!-- or name="..." -->
>  <resource url="..." filename=".." fileId="..." sql="..." ref="..."
> date="..." versionId=".." revisionId="..." type="...">       <!-- all
> optional -->
>    <taSetId value="...">
>      <taSetId value="...">
>        ...
>        <taId lineNumber="..." value="..."/>
>        ...
>      </taSetId>
>    </taSetId>
>  </resource>
>  </testAssertionRef>
>
> and if it is a reference to an internal TA | TASet/TA make
> 'resource' itself optional
>
>  <testAssertionRef>
>  <taSetId value="...">
>    <taSetId value="...">
>        ...
>      <taId value="..."/>
>        ...
>    </taSetId>
>  </taSetId>
>  </testAssertionRef>
>
> This nested XML design obviates having to define a convention
> with BNF so we can just provide the XML Schema plus prose
> (for this at least). If we do want the point-separated notation we
> can still have the attributes:
>
>  <testAssertionRef id="..." url="..." filename=".." fileId="..."
> sql="..." ref="..." date="..." versionId=".." revisionId="..."
> type="...">abc.lmn.xyz</testAssertionRef>
>
>
> Not sure how to handle your comment about schemas though, Kevin.
>
>
> ---
> Stephen D Green
>
>
>
>
> 2009/9/18 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]