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 11:43 AM, Shawn <sgrover@open2space.com> wrote:

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


We always talked about a report back to the main TC.
I see that as the main way we can address these issues Peter.
I'll add it as a deliverable.

12. A report to the main TC identifying perceived areas of weakness
    either for interoperability or testability.

To me, that is the way the TC can comment on these areas.



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


+1, all the TC can do is report them as we find them. It is up to the main TC
to resolve them Peter.



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

Good point to feed back to the main TC in the  report.



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


Deliverable 9 will allow a user to identify extensions.
Our goal is to strengthen interop, so anything the TC can come up
with can be used to help us in that direction, but within scope.

> Having software forbin in charter as well also hamstrings.

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.


regards


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