OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tag-discuss] Reasons to wait on convening a TC


Not sure if this is a summary, though it reads well to me.
Just picking up on his 'astounded' expression.

On 28/11/06, david_marston@us.ibm.com <david_marston@us.ibm.com> wrote:


> The question of representing TAs in XML is still open, apparently. I was
> astounded when Dave Pawson wrote on 11/27/2006:
> >I really don't see that mandating XML as the way in which tests are
> expressed
>  >is useful? For some it will be that the XML will be an unecessary wrapper
>  >for simple text.
>  Perhaps Dave and others are unaware of how well XML has helped with test
> case metadata for XSLT/XPath/XQuery testing.
Note my signature. I've been an XSLT user since 98 when James brought out
XT. I'm quite aware of its capabilities.


There are two kinds of benefits:
> filtering of the collection down to relevant subsets, and re-purposing the
> data by XSLT transformations. Keep in mind that XSLT can produce a text file
> as output. For test cases, this means that the test case metadata can be
> transformed into a platform-specific script for sequential execution of a
> set of cases.
You presume too much for me. It would appear you have an end to end
solution mapped out. That seems inappropriate for a specifiction.


 For TAs, I think that well-designed markup might support
> "joins" of two or more TAs that eventually give the specs of what individual
> test cases do. In some cases, the specs could be further transformed into
> actual inputs for testing.

Does one detect a hard db background there :-)





>
> Even if we are unsure of the state of the art in automated reasoning over a
> set of premises, we can assume that someday it will be possible to process a
> set of TAs by software and obtain further value.
This is the first mention of reasoners I' ve come across. Is the intention
to solve this using AI implementations?



The further value might be
> about test coverage or test cases needed, or it may be about consistency in
> specs. If we design TAs to be amenable to machine processing (e.g., by
> expressing them in XML), then there is hope that early efforts at TAs will
> become more valuable in the future as new tools emerge.

A test matrix will do that.


>
> In addition to the workload imposed on the TC that would try to develop this
> specification, we must keep in mind that attempts to compose conformant TAs
> would increase the workload on the various TCs and WGs that attempt to use
> it. That's why my earliest remark in this forum was that the TAs have to
> contribute enough value to be "worth it" for the WG that uses them. I think
> such value can only be realized if the TAs are usable in automated testing.

Please excuse my scepticism there.

I still don't fee that you've justified the use of XML for test specifiction.

Sorry David, you remain astounded, I'll remain neutral on the solution
being expressed in XML.

What of a WG that doesn't have any XML expertise? Wouldn't that be making
it unecessarily hard for them?

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]