2008/6/30 <>:
> 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
