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

["Peter Dolding" <oiaohm@gmail.com>]

On Tue, Jul 22, 2008 at 6:45 AM, Shawn <sgrover@open2space.com> wrote:
> Peter Dolding wrote:
>>
>> Please pardon my 99 but I think we need it in there.  If the document
>> become unreadable to the people doing the testing and producing the
>> reports it becomes just another nightmare document.   Simpler the
>> document more likely it can be translated to other languages as need
>> and keep its meaning.
>>
>> 12.* Creation of central lists of documented and non documented
>> extensions to ODF found that are not part of the standard.  Until
>> equal is provided by the ODF standard body.
>> 13.* Implementer usable testing systems.(Complete Test of Standard)
>> 14.* End User Standard Conformance Verification.(Acid Tests)
>>
>> 99.*  Off the Street Human Readable Charter.
>
> some thoughts:
> - I know there was discussion of this central registry.  But I don't recall
> there being a consensus view that this should be in the document...  Then
> again, I've been in "skim" mode for the past week or so wrt this list.. :)
>  If a consensus was reached, then I'll remove this comment.  Peter, I see
> you as the "sponsor" for this idea, so no offense, but I'd rather hear of
> the consensus view from someone else.. :)

So far it has not resolved correct.   But as stated in my email for
before this to Dave Pawson. It has to be sorted out for the report
writer.

The other debates where covering work ability between implementers not
operation of the TC.

Mostly implementer complaining that they would have to report stuff.
They put up every option to try to find a way round to a effective
solution.   They did not without altering the standard get close to
something workable even then that solution was dicey.  There has not
been 1 solid alternative to central reporting put up that holes cannot
be punched straight all the other ideas once you try to go threw the
actions of using it.   Ok implementers don't 100 percent like it.
Most common complaint is that 1 party will be put in charge of the
repository.   1 party is in charge of the standard too so that is 100
percent invalid complaint.  Follows with this will stifle innovation
with no clear explanation of how other than that one body controls the
registry.   Sorry to say I see the arguments against it as nothing
more than smoke and mirrors.  Were the other ideas put forward try to
keep secrets forcing implementers to delete alterations to standard
they don't know so everything works out right.

They went as far as suggesting ODF documents have a key that tell the
document not to delete unknown parts.  Great how to expand the
standard without the standard bodies approval.   How to create a nice
lot of vendor lock in along the way.   Again unworkable.

schemes from w3c sounded workable until you saw it did not address the
key question how application would know if a key was harmful to there
document or not and if they should delete the key.  So still
unworkable.

None of the options against central repository truly was about
fostering work between implementers.  It was all about how can we have
our own private black box's in the standard.

I would not have pushed up here alone if there was a alternative that
works to reduce implementers complaining about other implementers
deleting there keys and was usable by the TC for its report create.
Do I have to create another lot of messy threads for people to throw
up unworkable ideas to get it past.

Basically its speak up time.  If they have something that works put it
up for the charter if they don't let the central reporting start until
they can come up with something that truly works.

Central reporting lives because so far nothing to truly compete
against it has been put up.  So how can we have a vote when there is
not two parties.  Yes its left in hard to resolve limbo.  It needs to
get out of limbo.

> - your section 13 contradicts section 1c - scope of work.  Specifically the
> phrase "The TC will not produce such software."  If by "systems" you mean a
> set of documents/guides for implementing testing, then I'd tend to be in
> agreement.  But that needs to be spelled out if sect 13 stays - but it looks
> like this type of "systems" is defined by the rest of the document anyways,
> so sect 13 seems redundant.

Ok we need 1c cleared up.   Because that could kinda nail us. for my
12 and 13 as well as doing any application testing.  Acid tests are
not applications for users to do work.  But if in time ODF has a
network part added to its spec and we need to test it we would have to
built test applications for that.  Same with if formal specs to
extensions appear.   Big issue is what is software.  If software
includes ODF macros we are complete stuffed building any test cases by
current charter.
>
> - sections 13 and 14 are close to suggesting HOW the TC will operate, rather
> than suggesting guidelines for achieving it's goal.  I think we could leave
> out both of these items, yet still have them encompassed - if/when the TC
> decides they need them.  I'm thinking about the early conversations here,
> regarding not putting specific limits (to how the TC may meet it's goals)
> into the charter.
Sorry I disagree.  Strongly.  Acid tests and implementer usable test
suits are common parts of most TC.   Including them in the charter as
deliverable is for a reason.  So some people don't get the idea that
they can create tests for conformance charge for them to fund the TC
effectively locking Open Source implementers out from getting there
hands on them.

Also having them in the charter acts as a back stop against like the
above mirror error.
> - Section 99 should NOT be in the definition of the TC charter.  That is
> covered by the FAQ deliverable, in my view.
I should have put documents.  I had just read the OASIS  charter idea
of charter was stuck in head.

Off the Street Human Readable Documents.   No killer legal terms and
the like sneaking in please.

Peter Dolding