Re: [oiic-formation-discuss] My perspective

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

2008/6/30  <robert_weir@us.ibm.com>:

> 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,

Not a consensus view IMO



>> 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.

Not a consensus view IMO

>>
>
> 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.

Not a consensus view IMO



> OK.  We've been calling such tests "atomic tests" since they test at the
> level of individual features of the ODF standard.

I agree with that. I don't think any call for consensus has been made.
Not a consensus view IMO



> We've been describing such tests as falling into one or two buckets:
>
> 1) Conformance tests would be tests that are traceable to formal provisions
> of the ODF standard.  So they are things that are testable relative to a
> specific shall/should/may, etc., in the text of the standard.  Violations of
> requirements (shall's) would be errors and violations of recommendations
> (should's) would be warnings.
>
> 2)Interoperability tests would contain further tests which might not be
> formally traceable to a shall or a should, but are stated as definitions in
> the text, or are clearly implied.  This would be a judgement call of the
> proposed OIIC TC.  For these items we probably do not want to score them as
> passing or failing, but as suggestions, based on the consensus of the TC.
>  To the extent ODF implementors run these interoperability tests and adjust
> their implementations based on this, then we will improve interoperability.

Not a consensus view IMO
I've only heard RW presenting this view.





>> 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.
>>
>
> This is a useful distinction.  We have a name for when an application drops
> data.  It is called "data loss".

Not a consensus view IMO




>  However, we can define an "ODF/Web" profile that
> defines exactly what subset of the ODF standard is losslessly mappable to
> the web toolkit, and by agreeing on this profile, we can achieve much
> greater interoperability between web-based word processors.  At the same
> time we allow traditional desktop word processors to have a "Save As
> ODF/Web" option.

Is that IBM Rob? Which 'we' are you referring to?




In summary, please don't put forward views as the groups until
you have asked for and obtained consensus.

regards


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