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

[Shawn <sgrover@open2space.com>]

Peter Dolding wrote:
 > 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

If I'm understanding correctly, your idea of a central registry is to 
help implementors with regards to their foreign keys/objects in an ODF 
document.  Correct?  If this is the case, may I suggest this is out of 
scope for the charter of a TC looking at how to test conformance and 
interoperability.  With that goal, it seems to me that anything NOT in 
the spec is out of scope.  There is still a problem to be addressed, but 
I suspect it is for another TC.

 > 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.

I'm hesitant for this TC to get into writing software.  As I see things, 
the focus of this TC is to identify WHAT needs to be tested.  Not HOW 
the test is implemented.  I would expect that the output from this TC to 
be a detailed requirements sort of document.  From which I can write 
code in the language of my choice, within the frameworks of my choice. 
In short - the software is up to someone else.  If the TC chooses to 
write software, so be it, but we should not mandate it in 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.

There was lots of talk about acid tests, and other such testing.  But in 
that I don't seem to recall any understanding that the TC would be 
responsible for building those tests - just defining the tests.  Again, 
same point as above.  But I'm just one voice.. :)

 > Also having them in the charter acts as a back stop against like the
 > above mirror error.

Having software deliverables in the charter hamstrings the TC when it 
comes time to do something different.  The TC becomes tied to what is in 
the charter.  If the TC determines that a software deliverable is not 
appropriate, but the charter says they need one, then an amendment to 
the charter is needed before they can proceed - or a new TC.  By not 
explicitly putting this requirement into the charter, the TC can choose 
to do software, or not - as THEY decide when their research is underway.

 >> - 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.

The discussion thus far for the FAQ deliverable is more aimed at the 
sorts of questions an implementor may be asking.  But there is nothing 
saying we cannot put a plain language explanation of the TC's charter 
into the FAQs as well.  The FAQ can easily serve as a tool to express 
ideas or concerns the public and/or implementors may want to hear about. 
  In my opinion.. :)

Shawn