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

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

On Mon, Jun 30, 2008 at 5:20 PM, Dave Pawson <dave.pawson@gmail.com> wrote:
> 2008/6/29 Thomas Zander <zander@kde.org>:
>
>> This brings up an important problem; when an implementation does not support a
>> certain feature at all, does that mean loading a document and saving it out
>> again will loose those features?  I think this is an important part of our
>> interoperability question.
>> To answer this question we have to make an important distinction between known
>> ODF features and unknown ODF features.  A known feature is something that is
>> detailed in the specification, but this implementation does not support.  For
>> instance because its text rendering engine is not powerful enough.
>> Completely separate from this is unknown metadata or plain foreign tags.  For
>> example an ODf implementation may add some new feature that is not (yet)
>> supported by ODF and it saves it in its own namespace. This new feature is
>> not possible to support for most other applications, but it may save the tag
>> out again.
>>
>> So, if anyone asks if an ODF application has round-trip preservation of
>> properties I want the first counter question to be if this is about known or
>> foreign properties ;)
>
>
> I'd prefer a simple definition.
> A known feature is define in the spec.
> An unknown one is not defined in the spec. Other name, an extension.
>
> Lets say vendor A doesn't implement/support  SVG?
> Is that a known feature or unknown, to that vendor?
> I'd define that as unimplemented. A test should reveal that.
>

Misses a critical one.  Where do you draw the line.

How long before we have a undocumented mess of private application
additions.  As a testing conformance undocumented messes cannot be
tolerated.

Min all extensions must be fully documented and put forward for
approval into the standard.  At this point as a TC asking for
tolerance to be considered will be taken seriously.  Reason you have
done everything you can to get that feature in the standard and to
work with others.   Of course the TC has the right to say different
way has been approved to do the same thing and you need to update your
application.

Now we have the reverse where its undocumented and never has been put
forward as a extension to the standard or put forward as a extension
but has black boxes we cannot give any tolerance.

Its a simple line solid and strict.  Anything else will screw up the
standard.   It has worked well for other standards.

Anything allowing undocumented blocks in the standard also gets on the
wrong side of a TC.   We want clear and above board documentation so
we can check that is working.  Not black boxes.

Peter Dolding