OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oiic-formation-discuss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

On Mon, Jun 30, 2008 at 6:23 PM, Thomas Zander <zander@kde.org> wrote:
> On Monday 30. June 2008 10:03:55 Peter Dolding wrote:
>> 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.
> I honestly think the above can be answered quite simple; at specific points in
> the specification we can add foreign properties and we can ask the
> implementation to store those unchanged.
> Naturally an ODF with <foo:bar>  or <bar:baz> doesn't know either and it
> typically can preserve neither, or both.
> So, IMOHO the drawing of the line is as simple as "implementation X preserves
> foreign properties at position Y in the spec, or not".
Please look at RTF.  Rich Text Format.  Same goals as ODF.  Complete
failed mess it allowed undocumented bits.

History tells us as soon as application can put undocumented
information in format is in trouble.  It also repeats with HTML and

Reason you will and I do me will get a ODF supporting application
exploit those foreign properties or any other undocumented section to
store information that enabled it to render differently to everyone
else so forcing everyone to use that program to get good output.

There is another reason for documentation.  And it is also critical.
We are about compatibility between vendors.  Not documented we could
have two foreign properties created by two different programs of
exactly the same name but with complete different operations.

Black Box's are no matter how you put it a breach of what the TC is
about.  Linux Standard Base like solution would be a central body to
store a register of all used foreign properties and approve assignment
before use anywhere.  This also prevents 1000 companies created 1000
different foreign properties to store exactly the same bit of

Now documented useful foreign properties other ODF applications most
likely will decide to keep alive.

Something needs to be done.  Its not the TC body job to fix it.   But
it is the TC job to block anything that goes against compatibility or
risks future issues.

"implementation X preserves foreign properties at position Y in the
spec, or not"  Simple why in hell bother. Its a undocumented mess in
breach of what TC has to protect.   When someone comes up with a way
to make it not a black box then we should change our mind about it.
Then we can test if it s being translated correctly.  Basically comes
a bit for us to test.

Peter Dolding

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]