[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [oiic-formation-discuss] TC formation proposal.
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]