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