W3C home > Mailing lists > Public > public-expath@w3.org > May 2012

Re: Exit Candidate criteria and Test Suite

From: Florent Georges <fgeorges@fgeorges.org>
Date: Thu, 10 May 2012 21:42:48 +0200
Message-ID: <CADyR_r1PSngiE=ctMmhA18HKjkd3bJr6x7KyazHYGCG3MM-RfA@mail.gmail.com>
To: Christian Grn <christian.gruen@gmail.com>
Cc: Innovimax SARL <innovimax@gmail.com>, public-expath@w3.org
On 10 May 2012 18:08, Christian Grn wrote:

> If I got it right, Saxon and Calabash (and Servlex?) are based on
> the very same implementation.

  Yes.  And no :-) They share the same Java implementation (the core
functionality) and they all have their own glue layer that links the
generic Java implementation to the product data model and other APIs.

  So on the one hand, you're right this is overestimating to count all
and every single one of them.  But on the other hand, each of them
tells that the module is implementable (and actually implemented) with
a particular processor (even though the processor-agnostic code is
shared).  Bit I am ok to count Saxon + Calabash + Servlex as one.

>> 1) Do we need to have a more stable specification system ( la W3C
>> Recommendation) or do we want to have a leaving specification ( la
>> WhatWG) ?

> To speed up the process, I would opt for a more liberal system.

  I think we have to find the right balance between a too formal
system, and a too liberal one.  I am more inclined to have a bit too
much liberal process than the other way around.  I think the current
EXPath process is rather liberal actually: for each spec, the editor
has as much freedom as he/she wants.

  Do you have anything specific in mind?

>> 4) Do we have some test suite already available ? At least is
>> someone already able to provide some tests ?

> We have written several JUnit tests for most of the implemented
> specifications..

  Good!  I am not sure JUnit is the best option to use when defining
the spec itself though.  My goal for EXPath was to have XSpec tests
for each module.  Sometimes XSpec is the perfect candidate.  Sometimes
it has to come with a companion (for instance for the HTTP Client it
comes with a custom HTTP server that serves specific responses so we
can test the requests).  Sometimes it is not suitable at all (for
instance for packaging, it makes no sense).

  I think having some guidelines and tools for unit testing is
definitely on the plus side, but each editor should be able to use
something else if he/she thinks that is more suitable (following some
kind of consensus).

  At least, I think requiring a (comprehensive) test suite for each
spec is good.  On the "how?", I'd tend to be more lenient, and I'd
give some freedom to the editors.

  Thanks Christian for your input!  What others think?


Florent Georges
Received on Thursday, 10 May 2012 19:43:37 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:52:20 UTC