RE: [tag] Referencing external test assertions

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

 >allow for a reference directly to a TA itself without a TA Set

I'd agree. We can expect the TA ids to be unique, in many instances. So that should suffice.

A separate importing mechanism may help with the files logistics, but I would keep it orthogonal to the "TA referencing" mechanism. In other words, whether the TA is in the same file or a different one, should not affect the syntax of the referencing. Only the logical constructs should be involved (TA, TAset).

We should not loose sight that Tas may be embedded in other documents (e.g. as annotations), that may have their own import mechanism.

-jacques

-----Original Message-----
From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf Of Stephen Green
Sent: Saturday, September 19, 2009 3:44 AM
To: TAG TC
Subject: Re: [tag] Referencing external test assertions

Also, it may be necessary to allow for a reference directly to a TA itself without a TA Set and where there is no need to specify a resource (say within the same document, as when a spec has embedded
TAs)

<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:element name="taId" type="taId_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>



---
Stephen D Green




2009/9/19 Stephen Green <stephen.green@documentengineeringservices.com>:
> Another pass at metadata for a TA resource
>
> Maybe we can avoid having codelists (enumerations) for resource type 
> by providing for further resource type metadata. A codelist would 
> never be exhaustive enough to be all that useful I think. Even the 
> further metadata leaves room for improvement (TA interoperability 
> profiles to add further attributes and restrict the existing ones for 
> known use cases, etc). Any implementation can add its own attributes 
> anyway though. Implementers may also need to define their won codes 
> for types like connectionType (e.g. DSN) and queryType (e.g. SQL), if 
> they use them. Confromance profiles might do the same (e.g. XPath).
>
> <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="docId" 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="resourceProvenanceId" 
> type="xs:normalizedString"/>
>    <xs:attribute name="resourceType" type="xs:normalizedString"/>
>    <xs:attribute name="resourceTypeVersionId" 
> type="xs:normalizedString"/>
>    <xs:attribute name="resourceTypeSchemaId" 
> type="xs:normalizedString"/>
>    <xs:attribute name="resourceTypeSchemaVersionId"
> type="xs:normalizedString"/>
>    <xs:attribute name="resourceTypeProvenanceId" 
> type="xs:normalizedString"/>
>    <xs:attribute name="connection" type="xs:normalizedString"/>
>    <xs:attribute name="connectionType" type="xs:normalizedString"/>
>    <xs:attribute name="query" type="xs:string"/>
>    <xs:attribute name="queryType" type="xs:string"/>
>    <xs:anyAttribute namespace="##any" processContents="skip"/>
>  </xs:complexType>
>
>
> I think this will work (at least when the referenced TA is in a TAML doc) e.g. :
>
>
>  <testAssertionRef name="707d047b-08d0-47c5-b4fe-3b70605e1f2f">
>            <resource
>    url="http://www.oasis-open.org/committees/download.php/34247/ubl-ta-draft-0-61.xml";
>               docId="ubl-ta-draft-0-61"
>               versionId="0.6"
>               revisionId="0.61"
>               date="2010-10-11"
>               resourceType="taml"
>               resourceTypeVersionId="0.6"
>               
> resourceTypeSchemaId="http://docs.oasis-open.org/tag/taml/draft/200909
> 14">
>                    <taSetId
>    value="Test Assertions for Universal Business Language v2 Invoice 
> Calculation Model">
>                        <taSetId
>                             value="invoice-total-001">
>                            <taId
>                                value="INVTOT001"
>                              />
>                        </taSetId>
>                    </taSetId>
>            </resource>
>    </testAssertionRef>
>

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