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

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

On Tue, Jul 22, 2008 at 11:43 AM, Shawn <sgrover@open2space.com> wrote:
> 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.
>
That is a major issue.  Spec currently includes flaws like
recommending preserving of non documented sections.  So as TC we are
nailed to wall by standard we are going to keep on getting
implementers wanting there undocumented sections living and the TC to
fail any other implementers for deleting them.

There have been disputes between OpenOffice and Koffice over each
other delete the other keys.   Same with others.    This is a
interoperability issue.  Has to be dealt with by someone.

Also you have other issues to worry about.  If you just stop at the
stuff listed in the standard this leaves the door open for
implementers to add keys that do features in a way that breaks
interoperability with other ODF programs even that it passes the TC
tests.  Then if we set up tests to make it fail if it processes if the
keys exist then we will be accused of bias.

Call it a nice no win.   Either we document the sections not covered
in spec so we can enforce against undocumented alignment alterations
and the like without being accused of bias because we gave them a
chance to tell them about them.  Or we risk interoperability being
destroyed between different applications by people expanding with
undocumented parts with any tempt to stop it called bias test casing.

There is a lot more here than just helping the implementers.   It also
giving the TC teeth.  The thing I am suggesting is many sided.

>> 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.
>
Having software forbin in charter as well also hamstrings.

There will be cases were verification programs will be needed of some
form.  Either as macros inside a odf document or something processing
and checking the document for invalid struts.

The two deliverable I put up.  Are nothing uncommon.

Peter Dolding