Re: [office] Evolving ODF, Interop and Multiple Implementations

["Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca>]

I find this discussion disconcerting:

If we wait until there are two (probably slightly different)
implementations of any feature before consider adding it to the ODF
standard, then we are essentially encouraging non-interoperability,
since once the implementation differ it is difficult to change then to
match.

Of course just adding features that no implemnetation implements or
plans to implement is pointless, but once there is an implementation
implementing or planning to implement a feature I would find it
advisable to discuss it and consider it for inclusion in the standard so
that if other implementations choose to add the feature too it can be
done in an interoperable way.

Andreas
 

On Thu, 2012-10-25 at 19:29 -0600, robert_weir@us.ibm.com wrote:
> André Rebentisch <andre.rebentisch@arsaperta.com> wrote on 10/25/2012
> 09:19:49 PM:
> 
> > From: André Rebentisch <andre.rebentisch@arsaperta.com> 
> > To: robert_weir@us.ibm.com, 
> > Cc: office@lists.oasis-open.org 
> > Date: 10/25/2012 09:20 PM 
> > Subject: Re: [office] Evolving ODF, Interop and Multiple
> Implementations 
> > 
> > Am 25.10.2012 23:57, schrieb robert_weir@us.ibm.com:
> > >> In principle parties are free to implement earlier incarnations
> of the
> > >> format.
> > > Yes. But that is not really an argument for deciding what
> additions we
> > > put into ODF 1.3.
> > 
> > You appear concerned that parties are capable to support a next gen
> > feature set, and raise a conformance issue: "If only a single
> > implementation will support a proposed feature, then existing
> > extensibility mechanisms should be used."
> > 
> 
> Actually, my point is that the purpose of ODF is (or should be, in my
> thinking) interoperability of documents among independent
> implementations.  That is why we are here.  If we want to create a
> standard for a single vendor then there are other models for how that
> can be done. 
> 
> Adding a single feature for a single vendor only is just one step
> along the path to adding many features for a single vendor, or even
> many features for several vendors, but implemented by only that single
> vendor.  The result is the same: a "feel good" standard that offers
> little real interoperability. 
> 
> I'd like to avoid us degrading the standard by "taking the easy way
> out".   If an implementation does not currently conform to ODF 1.2 the
> hard thing is to change the implementation.  The easy path is to
> change the standard.  I'm hoping we don't go down that path. 
> 
> -Rob 
> 
> 
> > Two cases
> > 1. Depth: Overcome underspecification, reduce ambiguity
> > 2. Scope: Add new capabilities
> > 
> > ad 1 no need to consider whether implementations do implement it in
> the
> > same way, the revised spec, the next version, _defines_ how it is
> > supposed to be. ad 2 here the implementation committment argument
> may
> > apply. Better not mix both up. At least one party is obliged to
> support
> > the ISO version.
> > 
> > >> >> In other words, I'd like to discourage adding capabilities to
> ODF 1.
> > >> >> 3 unless it promotes interoperability.
> > >>
> > >> Would that speed up the pace of development?
> > >>
> > > Development of the spec or the implementation?
> > 
> > Spec.
> > 
> > Best,
> > André
> > 

-- 
Andreas J. Guelzow, PhD, FTICA
Concordia University College of Alberta

Attachment: signature.asc
Description: This is a digitally signed message part