Re: Data flows

["G. Ken Holman" <gkholman@cranesoftwrights.com>]

At 00/06/26 17:25 -0400, David_Marston@lotus.com wrote:
>Ken wrote:
> >...before we get into file formats we still haven't yet discussed
> >the data flows that are up for discussion.  I think we need
> >agreement on the approach before we spend time deciding what each of
> >the files looks like.
>
>The main thing I'm wondering about is how we merge the contributed
>sets of tests and determine what is not yet covered.

If we base the methodology on ID-ing the parts of the spec and have the 
tests point into the spec with IDREFS then we can "invert" the links to 
determine which IDs do not have a corresponding IDREF.

>It looks to me
>like the contributors will be responsible for describing what they
>think each test is covering,

Yes.

>but the committee might have another
>idea when they look at how the test "contributes" to the goal of
>completeness.

Not only completeness, but perhaps we might have a different or additional 
area where we think the test makes sense being used.

>Furthermore, we'll need to settle on our mechanism
>for defining the correct output.

True ... and for testing the output.  If we want to do something simple 
like a "diff" of the two files, we may be able to use canonicalization ... 
but not where there is discretionary stuff like insignificant whitespace 
(either indent="yes" or method="html").

>Specifically, I'm thinking about
>the input/contribution stage: how much do we expect by way of
>explanation from the contributor?

We have to find a balance such that we don't inhibit contributions ... to 
encourage input, I'm willing to have the contributor give us what they have 
for documentation and we get back to them saying "we need more for this 
one, and this one, etc.".

We cannot take on the burden of doing the documentation ourselves, or it 
will never get done ... I think we are obliged to rely on what the 
contributor has written and to spend our committee time validating what 
they have said they are testing is sufficiently being tested.

Would we publish that aspect of our work that defines the breakdown of the 
specification into separate ID-able areas and ask they reference through 
IDREFS attributes the sections each test covers?

............. Ken

--
G. Ken Holman                    mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.             http://www.CraneSoftwrights.com/m/
Box 266, Kars, Ontario CANADA K0A-2E0   +1(613)489-0999   (Fax:-0995)
Web site: XSL/XML/DSSSL/SGML services, training, libraries, products.
Book: Practical Transformation Using XSLT and XPath ISBN1-894049-04-7
Next instructor-led training:    2000-09-19/20,2000-10-03,2000-10-04,
-                                    2000-10-05,2000-11-13,2001-01-27