Steffen Schwigon
2012-12-20 11:34:06 UTC
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
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
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
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
________________________________
Sent: Wednesday, November 9, 2011 6:25 PM
Subject: Re: [tap] W3C Evaluation and Report Language (EARL)
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.
- 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
[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
--
Dresden Perl Mongers <http://dresden-pm.org/>
_______________________________________________
tap mailing list
https://www.ietf.org/mailman/listinfo/tap
Sent: Wednesday, November 9, 2011 6:25 PM
Subject: Re: [tap] W3C Evaluation and Report Language (EARL)
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 specsuse 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.
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.
- 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
[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
--
Dresden Perl Mongers <http://dresden-pm.org/>
_______________________________________________
tap mailing list
https://www.ietf.org/mailman/listinfo/tap
--
Steffen Schwigon <***@renormalist.net>
Steffen Schwigon <***@renormalist.net>