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

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

2008/7/22 Peter Dolding <oiaohm@gmail.com>:
> The added 12 deals with my major issue.  Back talk is required.  I
> would change the "A report"  bit.  We really need to up stream them as
> soon as we have them proven to be processed by the TC at next meeting
> or main TC mailing list in case they are really quick to resolve.
> Reports instead of a report.  With formal meeting reports ordered in
> most critical to least.

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.




>> The charter says the TC will not produce software.
>> As a test implementer, any TC member is quite free to use
>> the output of the TC to write software?
>> Just that software will not be a main deliverable of the TC!
>> The TC needs to produce good test specifications so that
>> a test writer can use them.
>
> That is the point that is not clear.  Current wording any TC member
> could risk being picked on over creating automated or other forms of
> test suits.


Not as I see it Peter. You are part of this group, we have no right
to shout at you for what you do in the evening?
I don't see that as an issue.


>
> Test implementers bit needs to be made clear as part of there job of
> testing applications they might be coding automated tools.

That is later, could be the TC will specify that such
tools are needed. Not something for the charter, which only
gets the TC started.


>
> Now down to implementers tools and end user testing(acid test).
>
> All implementers tools goal is a complete test of all parts of current
> standard seeking to provide a detailed display of pass failure or
> other wise.   Clear report output  with references to standard for
> all failures.

Looks like we have a difference there. My view on terms:
A test tests some part of ODF.
A tool helps me run that test (or a group of tests).
Test results are produced by running a test or group of tests.
The test identity should link it back to the part of ODF being tested.

Do you have different definitions? Or was that just to separate
these types of test from user tests (acid tests)


>
> end user testing(acid test) Normally something with percentage or a
> graphic displayed to user with the means to access deeper to get the
> developer information.  This is also for speed targeted as the worst
> causes of incompatibly existing.  Less detailed coverage equals lot
> shorter time to complete the test.  Due to acid tests being simple to
> use we could ask everyone to like visit the TC site download the test
> and post a report back.  As a form of random sampling.  Even doing it
> as like a slashdot thing.  Where a full test suit does not work.

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?

So the deliverable might be

xx. A specification of a test suite testing interoperability areas
(developed from *1) in which requires no user intervention,
runs in a relatively short time and presents a results summary to the
user. This class of test is sometimes known as
acid testing.

Does that get it?





>
> These are the two groups of standard testing systems.  Both most
> likely can be put under a better title.
>
> 13. Start Collecting Test Suite/s Targeting implementers and End Users
> to acquire information on the implementation status of ODF from
> different existing test writers.

Where are you going now? This sounds like something the TC should
be doing, not us?



>
> Collection of created ODF test suite's really need to start of the get
> go.  No point have new test written if existing ones are up to snuff.

See our references on the wiki site.
http://sites.google.com/a/odfiic.org/tc/Home/tc-charter/existing-technical-work

They are in the charter already. Section 2a.


>
> Ok wording of 13 might need another rework.  We don't need any
> developed test cases disappearing into the mail list or anywhere else
> to be lost for ever.  Building the complete test system is going to be
> enough work once.
Your 13.* Implementer usable testing systems.(Complete Test of Standard)?
If so, I *think* that is what I'm talking about with *3.
The specification of a full set of tests for ODF. Do you think it sounds
like something different? I'm not going to say who writes the test. That
belongs after the TC IMHO.



>
> I guess this will be altered one we are up and running.  Or there will
> be defined side allowances in the charter.  Remember you have to read
> the charter and remember if a implementer can use it as a sledgehammer
> to stop us from saying there implementation is crap they will.   Ie
> that is outside the charter of what you should be doing.

Hopefully there will be enough honest men|women on the TC to keep
the group as a whole honest.


>
> Its the reason why I am reacting so bad to when people say if its not
> in the spec its not our problem.   It is our problem.  We are to check
> that implementations are compatible anything that stuffs with that is
> our issue.

Half with you, half says you're wrong. I think the TC will have enough
room to do something with incompatibilities found during testing.



>
> They are a lot harder to write than a lot of people think.  Yes they
> have to restrict but they have to clearly allow anything you many need
> to do.  Even if you never do it.

It needs to be tight enough so we get what we want, slack enough
so the TC can improve on what they are tasked to deliver.


> PS I hate writing charters all the looking over shoulder you have to do.

Shit happens Peter.
It needs doing if we want a good charter to start the group
on the right direction.


ps. Can we start a new thread please. The energy is on the deliverables.
I'll post an updated list later today my time.

I've noticed a duplication on canonicalization.
* 6 and *4
I'll correct that too.


regards



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