office message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [office] Evolving ODF, Interop and Multiple Implementations
- From: robert_weir@us.ibm.com
- To: office@lists.oasis-open.org
- Date: Thu, 25 Oct 2012 21:29:58 -0400
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é
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]