- From: Florent Georges <fgeorges@fgeorges.org>
- Date: Thu, 10 May 2012 21:42:48 +0200
- To: Christian Grün <christian.gruen@gmail.com>
- Cc: Innovimax SARL <innovimax@gmail.com>, public-expath@w3.org
On 10 May 2012 18:08, Christian Grün 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? Regards, -- Florent Georges http://fgeorges.org/ http://h2oconsulting.be/
Received on Thursday, 10 May 2012 19:43:37 UTC