Re: [oiic-formation-discuss] My perspective. Extensions

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

On Tue, Jul 1, 2008 at 11:51 PM,  <robert_weir@us.ibm.com> wrote:
>
> "David Gerard" <dgerard@gmail.com> wrote on 07/01/2008 03:26:10 AM:
>
>> 2008/7/1  <robert_weir@us.ibm.com>:
>>
>> > I'm aware of this behavior in the past.  In fact through the 1980's and
>> > 1990's almost all word processors relied on document formats that were
>> > proprietary and mostly undocumented.  However, I am not aware of this
>> > being
>> > a problem with ODF applications today.  Maybe someone can point me to an
>> > example of where this is a problem?
>>
>>
>> That's like saying "I am unaware of ODF mail clients today that
>> encourage automatic execution of data as code, so there's no reason to
>> discourage it." Surely it's inherently problematic behaviour and its
>> direct encouragement of failure of interoperability has been
>> explained. Is there any actual useful reason to encourage it, thus
>> constructing a loophole the size of an eight-lane freeway tunnel?
>>
>
> I guess that comes down to the purpose of the TC.  If the purpose of the TC
> is to improve ODF interoperability, then I think that documenting,
> publicizing and enforcing guidelines that no one is breaking would be low
> priority on our list.  Improving interoperability needs to start from
> evaluating what causes interoperability problems now, today, and providing
> solutions to those problems.
>
> We'll aim to be comprehensive in the end, and cover all of the ODF standard,
> including statements about extensions, etc.  But if we look around and find
> that say, no one today is currently extended ODF, but that 80% of
> implementations are getting nested tables wrong, then wouldn't we start our
> work by defining test cases for tested tables?
>
Sections of major defects would be up there.    What is the point of
building tests for sections that everyone is getting right.  Its like
ok that makes them look good but does nothing for the standard so
worthless to the TC.

This where you have to learn to think different.  As a TC its all
about improving standard following.  This includes on purpose
targeting worst defects so they are clearly brought out of the
shadows.   Higher the percentage of failure the more critical it is to
build a test case.

100% of all implementations get is wrong that is like in critical need
of a test case so they know they are getting it wrong and how it
should be fixed.   Now if something only 10% percent of
implementations is getting wrong this is something they can most
likely correct by looking at the other implementations out there so
how critical a test case is lowers.

80% would be still quite critical.  Since the bad out number the good
and you cannot expect it to sort itself out threw natural compare to
competitors.

This is the difference between being a TC person and a implementer.
TC is there to provide tools and information to implementers to get
out of areas that everyone is getting wrong.   Implementers normally
only have to worry about being as good as everyone else without a TC.
 TC lets implementers to be better than everyone else and able to
prove it if they want to go after the standard.   Resource allocation
in the TC has to be a lot different to a normal Implementers resource
allocation due to what it is.

This is why it is so hard to come from being a implementer and run a
TC.   Everything about being a Implementer is pushing you towards
making the wrong selection as a TC runner.   All TC questions have to
be answers in the prospective what provides the most chances for
implementers to make a 100 percent confirming program without
compatibility issues with other confirming programs.

Also TC has to be prepared to make a stand on sections that are not
documented and risk long term compatibility issues even if your
companies implementation happens to be using them.  As long as your
Bosses are happy that if the time come between the TC and your company
that you could make a selection in the long term TC interest at the
cost of the company you are working for.  There will be no long term
headaches for you.   I would get this in writing before we are too far
into this TC development process it is simpler for us to change lead
now.

Peter Dolding