[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Referencing external test assertions
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]