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" <>
wrote on 06/30/2008 09:34:22 AM:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: oiic-formation-discuss-
>
> For additional commands, e-mail: oiic-formation-discuss-
>
>
