Re: [tag] Referencing external test assertions

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

I hope to work out in a new draft a way to denote several
TAs by a pattern. A way Jacques has mentioned offlist
is to use some kind of XPath pattern such as to show
using the XPath pattern "//taml:testAssertion" that all
TAs under the root element are members of the given set.
That way the TAs don't have to actually be contained by the
TA Set element but can be spread throughout a TA-related
marked up document (such as a docbook or xhtml document).
I have in mind that the purpose of the 'testAssertionSet' will
then be to provide the header-like information for the potentially
interspersed set of TAs, containing the data common to those
TAs but not the TAs themselves. This seems to be a natural
progression from the idea of a TA set which lists TAs by their
reference but in this case the TAs are listed by the pattern
they share of being represented in the same marked-up
elements contained in the same XML document. I guess then
that this is a special case of using a pattern to represent a
list of TAs, rather than an explicit list, but avoids the pitfall
of using a risky pattern like we point out in the guidelines
with the example of a range of values denoted by the first and
last TA IDs, separated by an ellipsis. Were we to introduce
into the markup a more general purpose testAssertionListPattern
it would be at risk of misuse since it might be that the list
does not provide adequate control of the criteria of membership
of the list (a ID within the range might be introduced later without
the awareness that this ID would put it into that list). The more
general kind of element I'm considering would use the more
stringent and self-limited criterion of membership of the list, well
known as a general list control method, that a TA is in the list
if it is contained in that document. The special case is that the
list is demarcated by containment in the XML document. This
special case warrants a special element and element name.

Perhaps it actually warrants a special kind of testAssertionSet
which has the document itself as the set. I therefore propose
to create a new element in the markup called a
'testAssertionDocument' with a special but limited kind of header.
This element does not however have to be the top level node of the
instance. In fact it might be better to call it
'testAssertionDocumentHeader'. It would contain just a small set
of elements surrounded by a container element called 'common'.

Perhaps it would be explicit in the semantics that it implicitly lists
all test assertions contained within the same XML outer document
element. Alternatively it could be we add an explicit element to
define a pattern within the 'testAssertionDocumentHeader' which
allows for alternative patterns to be defined to show which TAs
in a document are members of the overall test assertion set (or
test assertion document). This would cater for other forms of
markup for TAs, other than TAML, say. For instance the TAs could
be denoted as sets of rows in an XHML, docbook or CALS table.
It could also mean that a document can have more than header.

I think this is rather advanced at present so I am minded to start
with a default implicit rule in the semantics that states that all
'testAssertion' elements in the same XML document as the
'testAssertionDocumentHeader' are to be considered members of
that test assertion document denoted by the header and that the
'common' element data (such as 'title', 'author', 'date', etc) apply to
all such TAs. It would also be a default for this markup that there's
only one testAssertionHeader per document (but an advanced rule
could say that if there is a pattern definition in the header, perhaps
an extension element beyond the scope of the markup, and that
pattern is not default but explicitly defined, then there can be more
than one such header).

I'll aim to try this out with a new iteration of the schema but would
like to hear alternatives, objections, etc.

I would also like to add a 'report' element to the markup to allow
for 'markup-specific' (TAML implementation specific) uses where
the markup can be combined with outcome-related information. I
guess this is overlapping a bit with our ongoing considerations of
W3C EARL, but I would keep it very limited and allow for extension
using xsd:any when people have particular uses for the markup.
After all one whole point of using markup is to get downstream
use out of the test assertions and this really requires some level of
linkage to typical usages of this test assertion markup language, or
at least the scope for implementers to add such usage-related
elements as extensions without their having to break conformance
with the markup and its spec and schema. Having a minimal set of
elements under a repeatable and extendable 'report' element would
facilitate greater usage of the TAML markup.
---
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
>
>