[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]