Re: [oiic-formation-discuss] My perspective

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

On Mon, Jun 30, 2008 at 10:56 PM,  <robert_weir@us.ibm.com> wrote:
>
> Thomas Zander <zander@kde.org> wrote on 06/29/2008 05:34:56 PM:
>
>>
>> To give my perspective on how to do conformity checking, I want to give my
>> view on what ODF is.  This may sound strange to you as we all know what
>> ODF
>> is, right? But actually I realized that a lot of people have only a very
>> different and often limited set of usecases in mind when they think about
>> ODF.
>> ODF has been created for an office suite, applications that show you a
>> text
>> document or a spreadsheet and that want to save that.  This is a valid
>> usecase, but a simple one.
>> More exiting usecases are things like:
>> * website generates a ods file for download. So if you have a website that
>> gives you access to all your (or your companies) contacts you can download
>> a
>> selection and use that in your spreadsheet or in your word processor for
>> mailmerge.
>>
>> * ODF combines things like svg and mathml, which means it can be used as a
>> file format for clipart. Meaning can be that your vector graphics get
>> stored
>> in ODF, but also a text-snippet or just a logo. I'll let you come up with
>> usecases yourself, but there are plenty ;)
>>
>> * Currently the format of choice when doing rich text is html. So, if I
>> copy/paste or I email, html is created. This is sub-optimal. Html isa
>> broken
>> format on many levels and has various security problems as well. Much
>> better
>> would be to use ODF as a clipboard or email format. Usecases range from
>> having the ability to copy paste all text you have on your desktop (all
>> text
>> entry fields) as odf so simple annotations but also things like bold will
>> survive copy paste. Sending emails as ODF xml streams is something I think
>> will happen in under 5 years.
>>
>
> These are good points to be reminded of, especially when we mention
> interoperability.  We sometimes risk dwelling too much on person-to-person
> exchange of documents, and defining interoperability purely with respect to
> that use case.  But as a free, open, XML-based standard, ODF lends itself to
> server-based processing and other modes of use.  For server-to-server use,
> say indexing for a search engine, information extraction, combining
> documents, report generation, etc., the UI rendering is totally irrelevant.
>  In these cases the most important factors for interoperability are validity
> (from schema perspective) and the simplicity of the data and meta data
> models.
>
>
>> This short list of different fields of use show that there are a lotof
>> things
>> to consider when looking into the issue of interoperability. For instance,
>> do
>> we require copying text from a full-blown word processor and pasting that
>> into a simple text field to preserve bold/italic data when at a later
>> point I
>> copy that same text again and paste it into my rich-text editor in my
>> email
>> application.  The textfield would not be able to show this data, so
>> copying
>> it out later again seems a bit odd.
>>
>> So, the point I'm trying to make here is that if we want to have ODF
>> working
>> across a large range of usecases having a simple metric of rendering or of
>> preserving doesn't make much sense. It would likely just hamper uptake
>> since
>> the most exciting usecases would not be able to claim ODF compliance.
>>
>
> It is a balancing act.  In a sense, the ODF TC can define conformance
> however it wants.  We can have a very loose definition that makes many
> applications conformant.  Or we can have a very strict definition that no
> existing ODF application can pass.  I don't think it makes sense to define
> conformance for ODF to be such that only heavy-weight, traditional desktop
> editors can claim conformance.  Doing so would risk leaving out the most
> interesting and vibrant part of the market today.
>
This is exactly why I said TC should not be headed by implementers.
But by neutral organization.    We cannot care if everyone fails.
Look at the html acid tests when they were released not one rendering
engine passed.

You just made the same claims as Microsoft made for why failing the
first Acid Test was fine.

The key thing is that we can order the applications from the most
conformant to the least and be able to tell implementers what section
of there program is not working correctly so they can fix it.   This
is a TC not some ok you have a defect you can slide place.

Undocumented sections of standard and Applications not following
standard are the two sections we always have to have issue with.
Part of being a TC bending peoples noses out of joint from time to
time is required even if its your own company robert.

Peter Dolding