- From: Phil Archer <phil@philarcher.org>
- Date: Wed, 17 Dec 2008 15:40:34 +0000
- To: Charles McCathieNevile <chaals@opera.com>
- CC: Anthony Kukurikos <anthony.kukurikos@gmail.com>, Public POWDER <public-powderwg@w3.org>
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 Wednesday, 17 December 2008 15:41:17 UTC