[odf-discuss] Rick Jelliffe suggestions for ODF supporters

[Daniel Carrera]

marbux wrote:
> -- SVG SHOULD NOT be harmonized on the ODF flavor of SVG. As with
> ODF's hijacking of SMIL and XForms, SVG is improperly implemented in
> ODF using unique OASIS namespaces.

I don't think anyone has suggested some form of "harmonization". I don't 
think that even makes sense. And I think that "hijacking" is grossly 
unfair and reflects a misunderstanding.

ODF uses a *subset* of SVG for 2D graphics. It doesn't use all of SVG 
because SVG is a huge specification. It is very difficult to make an SVG 
viewer that actually supports everything SVG supports. A subset of SVG 
is not SVG and it would be *wrong* of OASIS to use the SVG namespace for 
something that is not truly 100% SVG. Making a new namespace for the SVG 
subset that they use is precisely the right thing to do.

I don't know what the story with SMIL or XForms is, but I suspect that 
it is a similar situation.

It might sound romantic to say "ODF should use all of SVG untouched". 
But you'll quickly find that nobody can support ODF then, because SVG is 
as much work to implement as the rest of the specification.


> -- I'd like to learn how David Wheeler feels about reworking the
> Forumula SC's work to accommodate the way Excel is currently
> programmed. My understanding is that David and crew looked very hard
> at how Excel handles formulas and have worked hard and long hours to
> create a vendor-neutral formula specification.

The issue was discussed at length. The Formula SC never inserted 
gratuitous incompatibilities with Excel. But there are cases where Excel 
is simply *wrong*. It is wrong to make a specification mandate that 
applications give the wrong answer at times (which OOXML does btw).

In cases where Excel does not give the wrong answer, Excel should have 
no problem using ODF. In many (though many not all) cases where Excel 
does give the wrong answer, Excel could still use ODF. For example, 
imagine a function FOO(), where Excel's value is consistently off by 1 
(it is 1 unit too high). Excel is welcome to show the wrong FOO() to its 
users. Excel is welcome to say to users that FOO(2) is 4 where in fact 
it should be 3. But when Excel *saves* the document, in the ODF file 
Excel should put down FOO(2)+1. Now when a KOffice user opens the file, 
all the cells will have the correct value, though some formulas will 
look slightly different.

You can do this whenever there is a relatively simple way to convert 
between Excel's buggy function and the correct one. But there may be 
cases where there is no obvious conversion, like with date-related 
functions.

Daniel.