OASIS Open Document Format for Office Applications (OpenDocument) TC

I want to toss in this idea, for a possible criterion for how we evolve ODF into ODF 1.3.   As we know ODF has powerful extensibility mechanisms via foreign attributes and elements, in application-defined namespaces.  The ODF 1.2 specification has extended conformance clauses to handle these cases.  So any implementation should currently be able to extend ODF and still claim conformance, so long as they have the basics (the non-extended parts) in conformance. This leads to the question:  As we evolve ODF, when should we decide to add new capabilities to the specification versus leaving them as implementation-defined extensions? I'd like to suggest that we do this based on the existence of *multiple implementations* of the new capability, or at least of committed plans of multiple implementers to implement the new capability. In other words, I'd like to discourage adding capabilities to ODF 1.3 unless it promotes interoperability.  If only a single implementation will support a proposed feature, then existing extensibility mechanisms should be used. Thoughts? -Rob

I think this is an interesting notion. Thoughts: 1. Intentions to implement are difficult to take into account, since these are voluntary standards and there should be care about that. However, if there is some community agreement where an extension has been implemented successfully by more than one producer (i.e., there is already demonstrated interoperability of independent implementations), that would certainly carry some weight. Of course, it is often the case that working such an agreed feature into the specification will lead to adjustments as part of implementation-independence. 2. Another way to work this is the way that features progress in other venues, such as the IETF. There is early specification of a feature having mutual interest, but it stays in draft until there are implementations. It doesn't even get to the equivalent of a Committee Spec until interoperable use is confirmed and the rough edges adjusted, unsupported aspects removed, etc. And then it rolls into a Standard. This raises some problems around changes over time and the management of identifiers and namespaces for XML-based formats though. 3. It appears that another way to work on the lines of (2) would be to have provisional features, with provisional identifiers and namespaces, that are not confused with anything in the standard and occur as extensions in implementations. There is a way to also reserve what would be the adopted identifiers and namespaces, so that supporting consumers could accept either designations, but producers would only use the provisional identifiers and namespaces. If the feature doesn't make it into a standard in interoperable form with the extension, the reserved designations are never adopted. (The extension remains usable as an extension and there is never any confusion with an incompatible variant that makes it into the standard, since that would not conflict with the reserved ones that were not adopted.) 4. I am proposing something along the lines of (3) for changes to protection keys and also for changes in the key derivation in ODF 1.3. The proposals establish reserved identifiers that would go into a Committee Draft but would be abandoned if a subsequent Committee Draft or Committee Specification ended up with an incompatible definition -- requiring other identifiers. What's missing is any introduction of an OASIS namespace entirely for provisional use in extensions only. I presumed that community-agreement on extension identifiers for the provisional feature could happen outside of the ODF TC. But perhaps there is a way to also issue provision-for-extensions-only namespaces and identifiers. The proposals work either way, so long as the reserved designations are (1) never adopted or (2) never used for an incompatible provision. - Dennis
Original Message----- From: office@lists.oasis-open.org [ mailto:office@lists.oasis-open.org ] On Behalf Of robert_weir@us.ibm.com Sent: Monday, October 22, 2012 08:41 To: office@lists.oasis-open.org Subject: [office] Evolving ODF, Interop and Multiple Implementations I want to toss in this idea, for a possible criterion for how we evolve ODF into ODF 1.3. As we know ODF has powerful extensibility mechanisms via foreign attributes and elements, in application-defined namespaces. The ODF 1.2 specification has extended conformance clauses to handle these cases. So any implementation should currently be able to extend ODF and still claim conformance, so long as they have the basics (the non-extended parts) in conformance. This leads to the question: As we evolve ODF, when should we decide to add new capabilities to the specification versus leaving them as implementation-defined extensions? I'd like to suggest that we do this based on the existence of *multiple implementations* of the new capability, or at least of committed plans of multiple implementers to implement the new capability. In other words, I'd like to discourage adding capabilities to ODF 1.3 unless it promotes interoperability. If only a single implementation will support a proposed feature, then existing extensibility mechanisms should be used. Thoughts? -Rob

office@lists.oasis-open.org wrote on 10/22/2012 01:41:57 PM: > > I think this is an interesting notion. > > Thoughts: > >  1. Intentions to implement are difficult to take into account, > since these are voluntary standards and there should be care about > that.  However, if there is some community agreement where an > extension has been implemented successfully by more than one > producer (i.e., there is already demonstrated interoperability of > independent implementations), that would certainly carry some > weight.  Of course, it is often the case that working such an agreed > feature into the specification will lead to adjustments as part of > implementation-independence. > #1 -- This aligns with the assertions we make when we put forward out "Statements of Use" with a candidate OASIS Standard.  In that case we need three statements for the standard as a whole, although there are no strict interop requirements.  But if we are doing an incremental update of ODF, then it would be expected (IMHO) that new features added have been implemented by multiple vendors. #2 -- I'm sure we would fine things that require "adjustments" to the spec.  That is the value of implementation experience while developing the spec. >  2. Another way to work this is the way that features progress in > other venues, such as the IETF.  There is early specification of a > feature having mutual interest, but it stays in draft until there > are implementations.  It doesn't even get to the equivalent of a > Committee Spec until interoperable use is confirmed and the rough > edges adjusted, unsupported aspects removed, etc.  And then it rolls > into a Standard.  This raises some problems around changes over time > and the management of identifiers and namespaces for XML-based formats though. > There are also IPR issues with such an approach, if it involves another organization, not an OASIS member. But there are ways of doing this kind of approach entirely within the TC.  For example, we could have a document called "experimental features" or such that we track as a Committee Draft, even put out for public review, but it advances no further until we have multiple implementations. >  3. It appears that another way to work on the lines of (2) would be > to have provisional features, with provisional identifiers and > namespaces, that are not confused with anything in the standard and > occur as extensions in implementations.  There is a way to also > reserve what would be the adopted identifiers and namespaces, so > that supporting consumers could accept either designations, but > producers would only use the provisional identifiers and namespaces. > If the feature doesn't make it into a standard in interoperable form > with the extension, the reserved designations are never adopted.   > (The extension remains usable as an extension and there is never any > confusion with an incompatible variant that makes it into the > standard, since that would not conflict with the reserved ones that > were not adopted.) > If the provisional identifiers are not in the standard itself, then that sounds OK.  Otherwise we're just introducing another flavor of extended conformance. > 4. I am proposing something along the lines of (3) for changes to > protection keys and also for changes in the key derivation in ODF 1. > 3.  The proposals establish reserved identifiers that would go into > a Committee Draft but would be abandoned if a subsequent Committee > Draft or Committee Specification ended up with an incompatible > definition -- requiring other identifiers.  What's missing is any > introduction of an OASIS namespace entirely for provisional use in > extensions only.  I presumed that community-agreement on extension > identifiers for the provisional feature could happen outside of the > ODF TC.  But perhaps there is a way to also issue provision-for- > extensions-only namespaces and identifiers.  The proposals work > either way, so long as the reserved designations are (1) never > adopted or (2) never used for an incompatible provision. > >  - Dennis > > >
Original Message----- > From: office@lists.oasis-open.org [ mailto:office@lists.oasis-open.org > ] On Behalf Of robert_weir@us.ibm.com > Sent: Monday, October 22, 2012 08:41 > To: office@lists.oasis-open.org > Subject: [office] Evolving ODF, Interop and Multiple Implementations > > I want to toss in this idea, for a possible criterion for how we > evolve ODF into ODF 1.3.   > > As we know ODF has powerful extensibility mechanisms via foreign > attributes and elements, in application-defined namespaces.  The ODF > 1.2 specification has extended conformance clauses to handle these > cases.  So any implementation should currently be able to extend ODF > and still claim conformance, so long as they have the basics (the > non-extended parts) in conformance. > > This leads to the question:  As we evolve ODF, when should we decide > to add new capabilities to the specification versus leaving them as > implementation-defined extensions? > > I'd like to suggest that we do this based on the existence of > *multiple implementations* of the new capability, or at least of > committed plans of multiple implementers to implement the new capability. > > In other words, I'd like to discourage adding capabilities to ODF 1. > 3 unless it promotes interoperability.  If only a single > implementation will support a proposed feature, then existing > extensibility mechanisms should be used. > > Thoughts? > > -Rob > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: office-help@lists.oasis-open.org >

Two +1, below
Original Message----- From: office@lists.oasis-open.org [ mailto:office@lists.oasis-open.org ] On Behalf Of robert_weir@us.ibm.com Sent: Monday, October 22, 2012 12:25 To: office@lists.oasis-open.org Subject: RE: [office] Evolving ODF, Interop and Multiple Implementations office@lists.oasis-open.org wrote on 10/22/2012 01:41:57 PM: [ ... ] > 2. Another way to work this is the way that features progress in > other venues, such as the IETF. There is early specification of a > feature having mutual interest, but it stays in draft until there > are implementations. It doesn't even get to the equivalent of a > Committee Spec until interoperable use is confirmed and the rough > edges adjusted, unsupported aspects removed, etc. And then it rolls > into a Standard. This raises some problems around changes over time > and the management of identifiers and namespaces for XML-based formats though. > [ ... ] <orcmid rate="+1"> But there are ways of doing this kind of approach entirely within the TC. For example, we could have a document called "experimental features" or such that we track as a Committee Draft, even put out for public review, but it advances no further until we have multiple implementations. </orcmid> > 3. It appears that another way to work on the lines of (2) would be > to have provisional features, with provisional identifiers and > namespaces, that are not confused with anything in the standard and > occur as extensions in implementations. There is a way to also > reserve what would be the adopted identifiers and namespaces, so > that supporting consumers could accept either designations, but > producers would only use the provisional identifiers and namespaces. > If the feature doesn't make it into a standard in interoperable form > with the extension, the reserved designations are never adopted. > (The extension remains usable as an extension and there is never any > confusion with an incompatible variant that makes it into the > standard, since that would not conflict with the reserved ones that > were not adopted.) > <orcmid rate="+1"> If the provisional identifiers are not in the standard itself, then that sounds OK. Otherwise we're just introducing another flavor of extended conformance. Right, the provisional identifiers are not in the standard itself and are always foreign elements, attributes and attribute values with respect to the schema of the standard. They could be provided as a companion to the "experimental features" CD so that there could be experimental interoperability too, but they never become more than foreign. </orcmid> [ ... ]

Dear Rob, Am 22.10.2012 21:25, schrieb robert_weir@us.ibm.com: >> I'd like to suggest that we do this based on the existence of >> *multiple implementations* of the new capability, or at least of >> committed plans of multiple implementers to implement the new capability. In principle parties are free to implement earlier incarnations of the format. >> 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? Best, André

office@lists.oasis-open.org wrote on 10/25/2012 10:39:46 AM: > From: André Rebentisch <andre.rebentisch@arsaperta.com> > To: robert_weir@us.ibm.com, office@lists.oasis-open.org, > Date: 10/25/2012 10:40 AM > Subject: Re: [office] Evolving ODF, Interop and Multiple Implementations > Sent by: office@lists.oasis-open.org > > Dear Rob, > > Am 22.10.2012 21:25, schrieb robert_weir@us.ibm.com: > >> I'd like to suggest that we do this based on the existence of > >> *multiple implementations* of the new capability, or at least of > >> committed plans of multiple implementers to implement the new capability. > > 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. > >> 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? -Rob > Best, > André > > --------------------------------------------------------------------- > To unsubscribe, e-mail: office-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: office-help@lists.oasis-open.org >

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." 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é

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é >

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

Rob Weir wrote: > I'd like to suggest that we do this based on the existence of *multiple > implementations* of the new capability, or at least of committed plans of > multiple implementers to implement the new capability. > Hi Rob, I would presume some level of endorsement by multiple implementers is already implied when new features get voted in to ODF. I'm unconvinced we should add more ceremony at this point, possibly leading to an even slower evolvement of ODF? > In other words, I'd like to discourage adding capabilities to ODF 1.3 > unless it promotes interoperability. > There is a certain circularity in this argument. If a majority of the TC deems an addition or change to ODF useful, we should get it in. Best regards, -- Thorsten Behrens SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Attachment: pgpcNEcEJZorU.pgp Description: PGP signature

office@lists.oasis-open.org wrote on 10/25/2012 04:34:21 AM: > > Rob Weir wrote: > > I'd like to suggest that we do this based on the existence of *multiple > > implementations* of the new capability, or at least of committed plans of > > multiple implementers to implement the new capability. > > > Hi Rob, > > I would presume some level of endorsement by multiple implementers > is already implied when new features get voted in to ODF. I'm > unconvinced we should add more ceremony at this point, possibly > leading to an even slower evolvement of ODF? > If we did not include features that only one implementation used, then our work on ODF 1.3 would be faster, due to not engaging in specification of those features, right?  But not by much.   > > In other words, I'd like to discourage adding capabilities to ODF 1.3 > > unless it promotes interoperability. > > > There is a certain circularity in this argument. If a majority of > the TC deems an addition or change to ODF useful, we should get it > in. > That is not circularity.  That is just saying that majorities can be unwise at times.  We already know that. We can look at standards like the EJB spec, where the various vendors went in and each added their own special settings and behaviors that in the end there was almost no interop at all.  It was a purely a standard for the marketing department.   I'm not looking to undo a majority here.  I'm only suggesting that we consider this carefully, when new features are proposed.  Why are we adding this to ODF?  Will anyone implement it?  Will it improve interop?  Would this be better off as a vendor extensions? -Rob > Best regards, > > -- > > Thorsten Behrens > > SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff > Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) > [attachment "att3fhic.dat" deleted by Robert Weir/Cambridge/IBM]

Rob Weir wrote: > I'm not looking to undo a majority here. I'm only suggesting that we > consider this carefully, when new features are proposed. Why are we > adding this to ODF? Will anyone implement it? Will it improve interop? > Would this be better off as a vendor extensions? > Hi Rob, sure sure - but it is my understanding that we were operating under these considerations all the time. I currently see no need to go beyond current process. Best regards, -- Thorsten Behrens SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg; GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg) Attachment: pgp83YoGMw0IX.pgp Description: PGP signature