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


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]