Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: [tap] W3C Evaluation and Report Language (EARL)
2 views
Skip to first unread message
Steffen Schwigon
Dec 20, 2012, 6:34:06 AM12/20/12
to ta...@testanything.org, per...@perl.org, Bruno P. Kinoshita
Hi!
Just saw this message which I did not see in the testanything nor the
perl-qa lists. The testanything.org wiki is indeed not accessible. Maybe
someone can help.
Kind regards,
Steffen
"Bruno P. Kinoshita" <brunod...@yahoo.com.br> writes:
> Hi all,
>
> For the last three weeks or so, testanything.org has been down. I
> tried pinging the tap mailing list, but got no response. Tried to
> contact Test::More maintainer to see if he knew someone with karma to
> update the web site but got no response so far.
>
> This is the last message I found in my inbox regarding TAP, so I
> apologize beforehand for bothering you all :-)
>
> Does anybody know where I can find one of the testanything.org
> administrators, please?
>
> Thank you in advance, and sorry for the trouble.
>
> All the best,
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
>>________________________________
>> From: Steffen Schwigon <s...@renormalist.net>
>>To: Christophe Strobbe <christoph...@esat.kuleuven.be>
>>Cc: t...@ietf.org; Shadi Abou-Zahra <sh...@w3.org>
>>Sent: Wednesday, November 9, 2011 6:25 PM
>>Subject: Re: [tap] W3C Evaluation and Report Language (EARL)
>>
>>Christophe Strobbe <christoph...@esat.kuleuven.be> writes:
>>> Report Language (EARL) and a few related specifications. EARL's core
>>> use case is reporting the results of accessibility evaluations of
>>> websites (i.e. accessibility for persons with disabilities), but the
>>> language itself is generic, so it can also be used in other
>>> contexts. The language is based on RDF;
>>> […]
>>> During our last call for comments, one of the reviewers asked the
>>> working group if EARL duplicates TAP's efforts, or vice versa. The
>>> working group thinks that this is not the case; we think that EARL
>>> could be an alternative report format for TAP if a TAP consumer could
>>> be written that produces EARL. For this reason, we thought it would be
>>> interesting to contact you and to make sure we are aware of each
>>> other's work.
>>
>>Thanks for sync'ing this back to us. I just skimmed through the specs
>>and it was indeed interesting. As far as I understand from my (very
>>short) skimming I think it's not that many duplication of effort as the
>>main difference is a philosophical one.
>>
>>- EARL is similar to other W3C specs in respect to specifying a
>> comprehensive snapshot of known existing topics. For example, it
>> particularly covers all known HTTP methods (POST, GET, PUT, …). That
>> enables it to build tools on top of it that sematically “know” what
>> the document is about.
>>
>>- TAP in contrast is about specifying test results, really just the
>> *result* focus without hard specification of the tested topic, i.e., a
>> single test has a “description”, so someone reading it knows what it
>> is about but that part does not have a specification.
>>
>> For instance, a test about a HTTP method could have any description
>> from “POST” to “that strange other method that I never remember but
>> always use when GET is not sufficient”.
>>
>>
>>See [1] for some related discussion of this aspect.
>>
>>In this respect I think TAP is more like your RDF with some extensions
>>from EARL to describe test success.
>>
>>That makes the use-cases of TAP and EARL a bit different:
>>
>>- TAP allows to be produced by anything simple without toolchain
>> support, like embedded devices with nothing but a “print” function,
>> but you can not *sematically* evaluate results.
>>
>>- EARL seems to require more heavy toolchain support to produce but
>> allows more semantic result evaluation.
>>
>>Converting TAP to EARL is difficult.
>>Converting EARL to TAP is easy.
>>
>>On the evaluation of TAP I can point to TAP::DOM and Data::DPath, which
>>provide a more structured approach to evaluate test results, see my “TAP
>>Juggling” slides[2], page 30ff.
>>
>>Kind regards,
>>Steffen
>>
>>
>>Footnotes:
>>[1] http://grokbase.com/p/perl.org/qa/2008/04/re-tap-l-user-supplied-yaml-diagnostic-keys-descriptive-version/11ymnpm2765ztojoinznq2lz5674
>>
>>[2] http://www.amd64.org/fileadmin/user_upload/pub/yapc_eu_2011_tapjuggling.pdf
>>
>>--
>>Steffen Schwigon <s...@renormalist.net>
>>Dresden Perl Mongers <http://dresden-pm.org/>
>>_______________________________________________
>>tap mailing list
>>t...@ietf.org
>>https://www.ietf.org/mailman/listinfo/tap
>>
>>
>>
>
--
Steffen Schwigon <s...@renormalist.net>
Just saw this message which I did not see in the testanything nor the
perl-qa lists. The testanything.org wiki is indeed not accessible. Maybe
someone can help.
Kind regards,
Steffen
"Bruno P. Kinoshita" <brunod...@yahoo.com.br> writes:
> Hi all,
>
> For the last three weeks or so, testanything.org has been down. I
> tried pinging the tap mailing list, but got no response. Tried to
> contact Test::More maintainer to see if he knew someone with karma to
> update the web site but got no response so far.
>
> This is the last message I found in my inbox regarding TAP, so I
> apologize beforehand for bothering you all :-)
>
> Does anybody know where I can find one of the testanything.org
> administrators, please?
>
> Thank you in advance, and sorry for the trouble.
>
> All the best,
>
> Bruno P. Kinoshita
> http://kinoshita.eti.br
> http://tupilabs.com
>
>
>>________________________________
>> From: Steffen Schwigon <s...@renormalist.net>
>>To: Christophe Strobbe <christoph...@esat.kuleuven.be>
>>Cc: t...@ietf.org; Shadi Abou-Zahra <sh...@w3.org>
>>Sent: Wednesday, November 9, 2011 6:25 PM
>>Subject: Re: [tap] W3C Evaluation and Report Language (EARL)
>>
>>Christophe Strobbe <christoph...@esat.kuleuven.be> writes:
>>> Report Language (EARL) and a few related specifications. EARL's core
>>> use case is reporting the results of accessibility evaluations of
>>> websites (i.e. accessibility for persons with disabilities), but the
>>> language itself is generic, so it can also be used in other
>>> contexts. The language is based on RDF;
>>> […]
>>> During our last call for comments, one of the reviewers asked the
>>> working group if EARL duplicates TAP's efforts, or vice versa. The
>>> working group thinks that this is not the case; we think that EARL
>>> could be an alternative report format for TAP if a TAP consumer could
>>> be written that produces EARL. For this reason, we thought it would be
>>> interesting to contact you and to make sure we are aware of each
>>> other's work.
>>
>>Thanks for sync'ing this back to us. I just skimmed through the specs
>>and it was indeed interesting. As far as I understand from my (very
>>short) skimming I think it's not that many duplication of effort as the
>>main difference is a philosophical one.
>>
>>- EARL is similar to other W3C specs in respect to specifying a
>> comprehensive snapshot of known existing topics. For example, it
>> particularly covers all known HTTP methods (POST, GET, PUT, …). That
>> enables it to build tools on top of it that sematically “know” what
>> the document is about.
>>
>>- TAP in contrast is about specifying test results, really just the
>> *result* focus without hard specification of the tested topic, i.e., a
>> single test has a “description”, so someone reading it knows what it
>> is about but that part does not have a specification.
>>
>> For instance, a test about a HTTP method could have any description
>> from “POST” to “that strange other method that I never remember but
>> always use when GET is not sufficient”.
>>
>>
>>See [1] for some related discussion of this aspect.
>>
>>In this respect I think TAP is more like your RDF with some extensions
>>from EARL to describe test success.
>>
>>That makes the use-cases of TAP and EARL a bit different:
>>
>>- TAP allows to be produced by anything simple without toolchain
>> support, like embedded devices with nothing but a “print” function,
>> but you can not *sematically* evaluate results.
>>
>>- EARL seems to require more heavy toolchain support to produce but
>> allows more semantic result evaluation.
>>
>>Converting TAP to EARL is difficult.
>>Converting EARL to TAP is easy.
>>
>>On the evaluation of TAP I can point to TAP::DOM and Data::DPath, which
>>provide a more structured approach to evaluate test results, see my “TAP
>>Juggling” slides[2], page 30ff.
>>
>>Kind regards,
>>Steffen
>>
>>
>>Footnotes:
>>[1] http://grokbase.com/p/perl.org/qa/2008/04/re-tap-l-user-supplied-yaml-diagnostic-keys-descriptive-version/11ymnpm2765ztojoinznq2lz5674
>>
>>[2] http://www.amd64.org/fileadmin/user_upload/pub/yapc_eu_2011_tapjuggling.pdf
>>
>>--
>>Steffen Schwigon <s...@renormalist.net>
>>Dresden Perl Mongers <http://dresden-pm.org/>
>>_______________________________________________
>>tap mailing list
>>t...@ietf.org
>>https://www.ietf.org/mailman/listinfo/tap
>>
>>
>>
>
--
Steffen Schwigon <s...@renormalist.net>
Karen Etheridge
Dec 20, 2012, 12:21:52 PM12/20/12
to Steffen Schwigon, ta...@testanything.org, per...@perl.org, Bruno P. Kinoshita, an...@hexten.net
That domain is registered to:
Registrant Name:Andy Armstrong
Registrant Organization:Hexten
Registrant Street1:Bridge End Barn
Registrant Street2:
Registrant Street3:
Registrant City:Garrigill
Registrant State/Province:Cumbria
Registrant Postal Code:CA93DR
Registrant Country:GB
Registrant Phone:+44.01434381641
Registrant Phone Ext.:
Registrant FAX:
Registrant FAX Ext.:
Registrant Email:an...@hexten.net
> >>> During our last call for comments, one of the reviewers asked the
> >>> working group if EARL duplicates TAP's efforts, or vice versa. The
> >>> working group thinks that this is not the case; we think that EARL
> >>> could be an alternative report format for TAP if a TAP consumer could
> >>> be written that produces EARL. For this reason, we thought it would be
> >>> interesting to contact you and to make sure we are aware of each
> >>> other's work.
> >>
> >>Thanks for sync'ing this back to us. I just skimmed through the specs
> >>and it was indeed interesting. As far as I understand from my (very
> >>short) skimming I think it's not that many duplication of effort as the
> >>main difference is a philosophical one.
> >>
> >>- EARL is similar to other W3C specs in respect to specifying a
> >>� comprehensive snapshot of known existing topics. For example, it
> >>� particularly covers all known HTTP methods (POST, GET, PUT, ???). That
> >>> working group if EARL duplicates TAP's efforts, or vice versa. The
> >>> working group thinks that this is not the case; we think that EARL
> >>> could be an alternative report format for TAP if a TAP consumer could
> >>> be written that produces EARL. For this reason, we thought it would be
> >>> interesting to contact you and to make sure we are aware of each
> >>> other's work.
> >>
> >>Thanks for sync'ing this back to us. I just skimmed through the specs
> >>and it was indeed interesting. As far as I understand from my (very
> >>short) skimming I think it's not that many duplication of effort as the
> >>main difference is a philosophical one.
> >>
> >>- EARL is similar to other W3C specs in respect to specifying a
> >>� comprehensive snapshot of known existing topics. For example, it
> >>� enables it to build tools on top of it that sematically ???know??? what
> >>� the document is about.
> >>
> >>- TAP in contrast is about specifying test results, really just the
> >>� *result* focus without hard specification of the tested topic, i.e., a
> >>� single test has a ???description???, so someone reading it knows what it
> >>
> >>- TAP in contrast is about specifying test results, really just the
> >>� *result* focus without hard specification of the tested topic, i.e., a
> >>� is about but that part does not have a specification.
> >>
> >>� For instance, a test about a HTTP method could have any description
> >>� from ???POST??? to ???that strange other method that I never remember but
> >>
> >>� For instance, a test about a HTTP method could have any description
> >>� always use when GET is not sufficient???.
> >>
> >>
> >>See [1] for some related discussion of this aspect.
> >>
> >>In this respect I think TAP is more like your RDF with some extensions
> >>from EARL to describe test success.
> >>
> >>That makes the use-cases of TAP and EARL a bit different:
> >>
> >>- TAP allows to be produced by anything simple without toolchain
> >>� support, like embedded devices with nothing but a ???print??? function,
> >>
> >>See [1] for some related discussion of this aspect.
> >>
> >>In this respect I think TAP is more like your RDF with some extensions
> >>from EARL to describe test success.
> >>
> >>That makes the use-cases of TAP and EARL a bit different:
> >>
> >>- TAP allows to be produced by anything simple without toolchain
> >>� but you can not *sematically* evaluate results.
> >>
> >>- EARL seems to require more heavy toolchain support to produce but
> >>� allows more semantic result evaluation.
> >>
> >>Converting TAP to EARL is difficult.
> >>Converting EARL to TAP is easy.
> >>
> >>On the evaluation of TAP I can point to TAP::DOM and Data::DPath, which
> >>provide a more structured approach to evaluate test results, see my ???TAP
> >>
> >>- EARL seems to require more heavy toolchain support to produce but
> >>� allows more semantic result evaluation.
> >>
> >>Converting TAP to EARL is difficult.
> >>Converting EARL to TAP is easy.
> >>
> >>On the evaluation of TAP I can point to TAP::DOM and Data::DPath, which
> >>Juggling??? slides[2], page 30ff.
> >>
> >>Kind regards,
> >>Steffen
> >>
> >>
> >>Footnotes:
> >>[1]� http://grokbase.com/p/perl.org/qa/2008/04/re-tap-l-user-supplied-yaml-diagnostic-keys-descriptive-version/11ymnpm2765ztojoinznq2lz5674
> >>
> >>[2]� http://www.amd64.org/fileadmin/user_upload/pub/yapc_eu_2011_tapjuggling.pdf
> >>
> >>--
> >>Steffen Schwigon <s...@renormalist.net>
> >>Dresden Perl Mongers <http://dresden-pm.org/>
> >>_______________________________________________
> >>tap mailing list
> >>t...@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tap
> >>
> >>
> >>�
> >
>
> --
> Steffen Schwigon <s...@renormalist.net>
--
> >>Kind regards,
> >>Steffen
> >>
> >>
> >>Footnotes:
> >>[1]� http://grokbase.com/p/perl.org/qa/2008/04/re-tap-l-user-supplied-yaml-diagnostic-keys-descriptive-version/11ymnpm2765ztojoinznq2lz5674
> >>
> >>[2]� http://www.amd64.org/fileadmin/user_upload/pub/yapc_eu_2011_tapjuggling.pdf
> >>
> >>--
> >>Steffen Schwigon <s...@renormalist.net>
> >>Dresden Perl Mongers <http://dresden-pm.org/>
> >>_______________________________________________
> >>tap mailing list
> >>t...@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tap
> >>
> >>
> >>�
> >
>
> --
> Steffen Schwigon <s...@renormalist.net>
Build a man a fire, and he's warm for a day.
Set a man on fire, and he'll be warm for the rest of his life.
. . . . .
Karen Etheridge, ka...@etheridge.ca GCS C+++$ USL+++$ P+++$ w--- M++
0 new messages