[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] Referencing external test assertions
Proposed extra XML Schema types to handle the testAssertionRef:
<xs:complexType name="testAssertionRef_type">
<xs:sequence>
<xs:choice>
<xs:element name="resource" type="resource_type" minOccurs="0"/>
<xs:element name="taSetId" type="taSetId_type" minOccurs="0"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="lg" type="xs:normalizedString"/>
<xs:attribute name="name" type="xs:normalizedString"/>
<xs:anyAttribute namespace="##any" processContents="skip"/>
</xs:complexType>
<xs:complexType name="resource_type">
<xs:sequence>
<xs:choice>
<xs:element name="taId" type="taId_type" minOccurs="0"/>
<xs:element name="taSetId" type="taSetId_type" minOccurs="0"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="lg" type="xs:normalizedString"/>
<xs:attribute name="url" type="xs:anyURI"/>
<xs:attribute name="filepath" type="xs:normalizedString"/>
<xs:attribute name="ref" type="xs:normalizedString"/>
<xs:attribute name="versionId" type="xs:normalizedString"/>
<xs:attribute name="revisionId" type="xs:normalizedString"/>
<xs:attribute name="date" type="xs:dateTime"/>
<xs:attribute name="dateString" type="xs:normalizedString"/>
<xs:attribute name="resourceType" type="resourceTypeCode_type"/>
<xs:attribute name="connection" type="xs:normalizedString"/>
<xs:attribute name="sql" type="xs:string"/>
<xs:attribute name="xquery" type="xs:string"/>
<xs:anyAttribute namespace="##any" processContents="skip"/>
</xs:complexType>
<xs:simpleType name="resourceTypeCode_type">
<xs:union memberTypes="resourceTypeBaseCode_type
resourceTypeCodeExtension_type"/>
</xs:simpleType>
<xs:simpleType name="resourceTypeBaseCode_type">
<xs:restriction base="xs:normalizedString">
<xs:enumeration value="xmlSchema"/>
<xs:enumeration value="taml"/>
<xs:enumeration value="html"/>
<xs:enumeration value="xhtml"/>
<xs:enumeration value="docbook"/>
<xs:enumeration value="xml"/>
<xs:enumeration value="javadocs"/>
<xs:enumeration value="predict"/>
<xs:enumeration value="code"/>
<xs:enumeration value="rdfs"/>
<xs:enumeration value="owl"/>
<xs:enumeration value="office"/>
<xs:enumeration value="pdf"/>
<xs:enumeration value="unstructured"/>
<xs:enumeration value="plainText"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="resourceTypeCodeExtension_type">
<xs:restriction base="xs:normalizedString">
<xs:pattern value="ext:\S.*"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="taId_type">
<xs:attribute name="lg" type="xs:normalizedString"/>
<xs:attribute name="value" type="xs:normalizedString"/>
<xs:attribute name="lineNumber" type="xs:integer"/>
<xs:attribute name="lineId" type="xs:normalizedString"/>
<xs:anyAttribute namespace="##any" processContents="skip"/>
</xs:complexType>
<xs:complexType name="taSetId_type">
<xs:sequence>
<xs:choice>
<xs:element name="taId" type="taId_type" minOccurs="0"/>
<xs:element name="taSetId" type="taSetId_type" minOccurs="0"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="lg" type="xs:normalizedString"/>
<xs:attribute name="section" type="xs:normalizedString"/>
<xs:attribute name="value" type="xs:normalizedString"/>
<xs:anyAttribute namespace="##any" processContents="skip"/>
</xs:complexType>
Some random sample data
<testAssertionRef name="GA1cNXrZCK0IF3v">
<resource
url="http://iDOfKrab/";
ref="jHZ-FGy4Kki"
versionId="0.6"
revisionId="0.61"
date="2010-10-11T22:24:51"
resourceType="taml"
xquery="_7E8cdg5uoan87">
<taSetId value="abc">
<taSetId value="efg">
<taId
value="xyz"
lineNumber="698"
lineId="V-X8gn"/>
</taSetId>
</taSetId>
</resource>
</testAssertionRef>
---
Stephen D Green
2009/9/18 Stephen Green <stephen.green@documentengineeringservices.com>:
> 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]