W3C home > Mailing lists > Public > public-powderwg@w3.org > December 2008

Re: Feature List

From: Phil Archer <phil@philarcher.org>
Date: Thu, 18 Dec 2008 13:24:03 +0000
Message-ID: <494A4EF3.10402@philarcher.org>
To: Public POWDER <public-powderwg@w3.org>
CC: Antonis Kukurikos <kukurik@iit.demokritos.gr>

I've been through the complete list of features and checked that the 
various tools I've created all meet the spec - but this is all very 
circular as I've devised the tests and decided unilaterally that the 
code I wrote passed... not the most strict of tests! I have had to make 
a number of adjustments during the course of this exercise.

I'm going to take a look now at the PPs written by Andrea and Stasinos 
as well as the XSLTs.

Meanwhile, the feature list is updated at 


Phil Archer wrote:
> Charles McCathieNevile wrote:
>> On Wed, 17 Dec 2008 12:15:36 +0100, Phil Archer <phil@philarcher.org> 
>> wrote:
>>> Anthony Kukurikos wrote:
>>>> ...One question: should we have tests for the
>>>> cardinalities of each include/exclude element? It is not a matter of
>>>> workload as it is trivial, I just don't know if it facilitates the
>>>> readability of the TS doc (which is of course an important matter 
>>>> but not as important as its usefulness).
>>> It's a matter of striking a balance between 'proving everything 
>>> works' and going over the top with a separate test for every last 
>>> thing. I lumped the IRI constraints together as a compromise on this. 
>>> It's only in/excludepathcontains and in/excluderegex that's allowed 
>>> more than once anyway - the rest are all 0 or 1.
>>> If you have a good test to hand, good - use it, but let's not over do 
>>> it!
>> Hmm. I think it is good to use any tests we have - they all help 
>> improve the quality of implementations (or find bugs). The balance 
>> question is more one of judging whether we even have enough tests of 
>> the different aspects to make a reasonable claim that we are done...
> No argument there Charles. All I'm getting at really is that, for 
> example, the first 'feature' is "Basic structure of a POWDER Document" - 
> well, that covers a bunch of MUSTs and SHOULDs immediately following 
> example 2-1 - which the validator tests for. I'm hoping we can avoid a 
> feature list that has a line for every RFC2119 keyword ;-)
> Working on thus list today, I admit I've fixed a few bugs in the 
> validator and processor - so the exercise is doing its job!
> Phil

Phil Archer
w. http://philarcher.org/
Received on Thursday, 18 December 2008 13:24:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:42 UTC