OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

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


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]