Re: [oiic-formation-discuss] TC formation proposal.

["Dave Pawson" <dave.pawson@gmail.com>]

2008/7/22 Peter Dolding <oiaohm@gmail.com>:
> On Tue, Jul 22, 2008 at 10:55 PM, Dave Pawson <dave.pawson@gmail.com> wrote:

>> Don't disagree. What I don't want to do is tell the TC how to communicate
>> with the main TC.
>>
>> Another option would be to require some sort of regular liaison between
>> the two committees, "to resolve conformance and compliance issues"
>>
>> Is that too vauge? Any suggested improvements please?
>>
>> None of which would resolve the issues the TC were dealing with
>> until the next release of the main standard.
>>
> Some cases could be resolved before next main standard.  Like if we
> find 2 or more parties using extentions that we don't have a clue what
> they are upto yet turn out to be the same thing just giving different
> names.   Alignment between them might happen just because the spot
> light is put on them.

Nothing to do with the standard, just implementations?
Not a bad idea having some sort of liaison with the vendors though.
Perhaps that is the same route? Guess they all are TC members.





>
> Other cases could be posting out clearer documentation to implementer.

Could do that via the FAQ deliverable?


>
> I am coming to the nasty felling we are going to have to ask the main
> TC what we can ask for them to deal with ASP.  And what we have to
> wait to next standard release to fix.   Ie where they are prepaired to
> sit down with implementers and sort it out.   So this is going to get
> a really nasty clause.

Yep. Negotiation. All we can get is a statement from the main
TC that 'it' will be fixed in the next release. If we're lucky
they'll give us the words that will go in the next release.
That's all we can ask for.



>

> I don't want to see good coders locked out because we did the rules
> wrong.  If a member of the TC wants to provide a test case they must
> not be blocked by the rules.  There test case could be really handy to
> us.

Nothing in the charter blocks them from coding.




>>> Now down to implementers tools and end user testing(acid test).

>> Testing my understanding.
>> 1. Run by an end user.
>> 2. Must be fully automatic.
>> 3. Targeted at known interop weaknesses (we don't have such a list yet).
>> 4. Must run in less than .... ten minutes?
>> 5. Presents a summary of passes and fails, possibly as a percentage.
>> (No graphics please, or at least graphics plus an accessible alternative)
>>
>> I'm missing the purpose of the tests. Is it just interoperability?




> Yours and my defines are close.  I am more looking from a motive and
> reason side.

I can see that and I'm OK with it. Just getting a deliverable is hard.


>
>> So the deliverable might be
>>

>>
>> Does that get it?
>>
> That does get it close.  Usage and need of the test is not cover.  Ie
> the surveying of most numbers of end users able to make sure what we
> think is true about compatibility is so.

We can't 'require' most number of users, we can only ask that it
be aimed at a large number?

How about

 xx. A specification of a test suite testing interoperability areas
 (developed from *1)  which requires no user intervention,
 runs in a relatively short time and presents a results summary to the
 user. The tests should be aimed to attract a large number of users
to maximise feedback to ODF.  This class of test is sometimes known as
 acid testing.



> Way I read *3 is you are talking about the quality tests themselves
> not how they will be presented to the implementers and users to use.

No Peter. A test requirement lists what has to be tested, not how.
And the tests are for conformance to ODF.
  How they will be presented to the user, and results presented is
the job for the implementers, i.e. further down the line.

Not sure how I can make that any clearer. Any suggestions?
Process would be, as I see it.

1. TC writes 'test X, you should see Y'
2. Implementer codes that as part of a test group.
Some other part of the TC output states how the results
are grouped, how they are made available to the tester
or person running the tests.


The charter only lists what the TC has to do. No more.






>
> We need to cover both quality rules of the tests both implementers and
> acid could be defined in *3.

I want to keep acid tests separate? The words above are for acid tests,
not the conformance tests. I think they are potentially quite different things.




The two sub sections one for
> implementers one for acid tests creating a document describing how
> they will be created layout and other wise handled.   It is possible
> for a implementer test and Acid test to over lap.  Hopefully in a way
> 1 giant test suit can be developed from all different parties to be
> used to effectively test stuff.

Yes, there may be overlap, but that's for the TC to find out.

I don't want to tie the TC down too much with detail.

I'll add the acid test deliverable and post to a new thread.



regards


-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk