Re: [oiic-formation-discuss] Thoughts on interop

["Dave Pawson" <dave.pawson@gmail.com>]

2008/6/13 Simon Calderson <caldersons@yahoo.co.uk>:

> Some thoughts I've had reviewing the last few days' discussion on this list. What strikes me is two things; a. a focus on replicating 'acid test' for ODF, and b. a focus on visual interop. I think both these things are mistaken.

Please be assured they are the recent topics, not the sole interest of
the group.


>
> To relate these issues back to the topic at hand, I'm not sure why the output of an interop TC would be of genuine use to
> end-users and ODF customers.

Ask a user who'se tried to lift documents from Office Suite A to
Office Suite B. I've cursed for many hours
tidying up after such a transform.

 >The 'acid test' is a good example of an interop spec. designed such
that browsers will fail; it's not a good example of a test >which says
much if anything about the overall conformity to a standard.. Indeed,
it would be dangerous to moot such interop >tests as a system of
validation for ODF implementations

I don't think it is that.

> it's very easy to use such tests as a cudgel with which to bash vendors, when in reality with a complex standard you can
> create tests which even good implementations will fail

Not sure about 'very easy', but point taken.



>
> In my opinion, the output of any interop TC should be focussed primarily for the use of vendors to improve their
> implementations,

Why 'primarily' please?  It's possibly a lot of work for a vendor to
improve compliance. If they are the only
target it's easy for them to ignore it.


> Using a "carrot" approach rather than "stick" makes it much more likely that vendors outside the "big guys" are
> going to want to participate, and allows the interop TC to focus on specific areas or features
> without putting all the pressure on the vendors whose implementations are weakest in those specific areas.

+1
Competition is the other.


>
> The audience of the interop TC ought to also include the ODF TC. I don't know if this has been mentioned already,
> but it's not like the ODF specification is in any way golden or perfect: the interop TC is certainly going to come to
> the conclusion that certain features (or lack of features) hinder interop, and it's only the ODF TC who
> are able to act on those suggestions.

+0. Side effects? :-)
(Sticks or carrots?)


>
> So, my suggestion for audience would be the ODF TC, and ODF vendors. That makes the audience
> narrow and specific, and the output can then be tailored to their specific needs.
> Trying to address everyone's needs will address none of them well, and trying to use interop cases
> as an ODF quality mark is bound to fail.

I think the main TC *should* listen to output regardless, but a good addition.
I would be loathe to leave the audience so specific though. I don't
see more deliverables
with a wider audience, do you?

>
> Finally, I would like to see much more thought given to non-visual interop.

Functional definition please Simon?


> As a good example, it seems that the formula ctte has already put a lot of effort into test cases to ensure
> mathematical consistency and correctness. Such a test system obviously would be of use to the interop TC,
> and from my point of view it's vastly more important that the information in a spreadsheet be correct than
> that the spreadsheet "looks" right. Ditto for documents - much more important that they can be shared
> and edited sanely on different implementations than that they look identical.

Non visual as in 'auditory'?
Non visual as in xml/schematron validation?
Non visual as in parsing formulae in a cell?

Definition of 'shared and edited' please? Inter-application? Two
locations, same app etc?

In general I agree. I wanted to get our rather 'vague' pixel perfect
idea out in the open, that was
my personal reason for trying to tie it down. I haven't, as yet, to my
satisfaction.

regards



-- 
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk