Re: test assertions - suggestion

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

I attach a set of a few strawman, pre-draft test assertions
for the testAssertion element of the markup language to
assess how we could even derive TAs from information in
schema and markup syntax represented in the spec.

Best regards

Steve
---
Stephen D Green




On 11 February 2010 17:40, Stephen Green
<stephen.green@documentengineeringservices.com> wrote:
> Just a suggestion here:
>
> While we ponder the public review period, how about we
> write test assertions for the two specs (model and markup)
> - at least make an exercise of doing so? To at least 'take
> own medicine' as it were.
>
> I guess we could decide that many aspects of the spec for
> the markup do not require much more than the simple TA
> predicate that the instance be as defined as valid by the
> schema (though the recent W3C note on assertions for
> 'widgets' for mobiles seems to counter that practice). The
> schema might be seen as effectively a set of optimised
> TAs perhaps for details of the markup, negating the need
> to duplicate such detail in the TAs. What other TAs might
> we need for the model and perhaps especially for the markup
> which cover areas not covered by the schema?
>
> Also, something I've come across when writing TAs already:
> could we think how best to distinguish 'universal' targets
> (target 'types'?) from 'particular' targets? For example, with
> TAs for a UBL invoice, a target might be 'invoice lines' in
> general - where the predicate applies to each and every
> invoice line in an invoice. On the other hand there might be
> a more particular target which is the invoice tax point date,
> of which it is a (perhaps implicit) prerequisite or assumption
> that there is only one in an invoice. Are there clear ways to
> cover these two use cases, which seem to me to be two
> clearly typical categories of use cases?
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>

taml-ta-set-0-1-pre-draft-0-1.odt