Re: [tag] Referencing external test assertions

[Stephen Green <stephen.green@documentengineeringservices.com>]

I hope to produce a new draft schema soon which trims down
the 'resource' type to mainly a uri plus some document
metadata (non technical such as date, identifier, etc). The idea
is people supply the technical details either in a test framework
or extra metadata / config settings and use the uri to point to
these (or some other such methodology).
---
Stephen D Green




2009/9/29 Stephen Green <stephen.green@documentengineeringservices.com>:
>> 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.
>
> So how much of this 'resource' type do we need? Do we
> need in the TA any metadata for any external resources?
> What kind of metadata do we need to uniquely identify a
> resource which contains TAs?
> ---
> Stephen D Green
>
>
>
>
> 2009/9/29 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
>>
>>
>