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