Re: [oiic-formation-discuss] My perspective

[robert_weir@us.ibm.com]

So noted, for the record.  Mr.
Pawson disagrees with everything I stated.

In fact, he'll probably even disagree
with this note.

-Rob
___________________________

"Dave Pawson" <dave.pawson@gmail.com>
wrote on 06/30/2008 09:34:22 AM:

> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: oiic-formation-discuss-
> unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: oiic-formation-discuss-
> help@lists.oasis-open.org
>