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: ODF 1.0 Maintenance + Synchronizationof OASIS:ISO/IEC

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 10/16/2008 
10:11:59 PM:

> ------------
> This must have been considered and I apologize for revisiting old 
> but I am curious if the current maintenance and incoming avalanche of
> defect-report items justifies another look:
OpenDocument-v1.0ed2-cs1 AS

It would be quite unusual to create a new OASIS standard for material that 
is older and inferior (in terms of accessibility, for example) to a more 
resent OASIS Standard, namely ODF 1.1.  In particular I don't think I 
would support sending something out for review and balloting as an OASIS 
standard that had known accessibility defects.  It sends the wrong 
message.  Sure, we could wave our arms and say it was purely for 
"alignment" purposes, but opponents will immediately latch on to the 
(apparent) regression in accessibility and go to town with that.

>    2.1 The idea would be to process Second Edition CS1 without changes 
> applied errata) and go through the pain of an OASIS Standard ballot 
> solely for the purpose of aligning with ISO/IEC now and for future
> maintenance of PAS-submitted OASIS ODF Standards.
>    2.2 The benefit would be to have a 2d edition of ODF 1.0 that is an 
> Standard and that is perfectly aligned with IS 26300:2006. 
>    2.3 We could now reconcile maintenance of ODF 1.0 with IS 26300 in a
> direct way (first, using the errata we already have) and not go into
> contortions where ODF 1.0 and ODF 1.0ed2 differ, and we could make 
errata on
> the Second Edition that are directly responsive to such items that come 
> with ODF comments and with defect reports from SC34.  Comments and 
> submissions involving substantive changes would be deferred up-level to 
> in-progress or subsequent version.
>    2.4 All subsequent OASIS ODF Standards (ODF 1.1 and ODF 1.2) are
> descendents of ODF 1.0ed2, so there is no discontinuity in the lineage 
> OASIS Standard specifications. 
> But, of course, it matters whether this is easily done under OASIS
> procedures and is considered worthy. 

I think we have a fishhook and the solution is to push it forwards, not 
backwards.  Push defect fixes forward to ODF 1.2 and then ensure that ODF 
1.2 is not changed in the ISO/IEC PAS process.  That will prevent future 

Remember, ODF 1.0 is not used by any major vendor.  Today IBM, Sun, 
Novell, even Microsoft are all on ODF 1.1 or ODF 1.2.  Real-world use 
requires the accessibility fixes in ODF 1.1, at least among the real-world 
adopters of ODF, which tend to be public sector and are legally obligated 
to provide accessible solutions. So fixing things in ODF 1.0 is of little 
practical consequence.   If ODF 1.0 were in wide use, I might agree with 

Now it would be more interesting to take all of the changes made in ODF 
1.1 (and you can see them in the appendix) and apply those, as errata to 
ODF 1.0 (second edition) and then make this be the common version between 
OASIS and SC34.  This would at least have the virtue of being a standard 
that is widely implemented.  But it would be a significant task to do 

> I am operating under the assumption that ODF 1.0 versions will continue 
> have overlapping lives and are generally intended to be upward 
> at least in the ODF 1.x series. 

Once a standard, always a standard.  The mere creation of ODF 1.x or 2.x 
does not eliminate ODF 1.0.  There is no process for undoing a standard in 
OASIS, though there is a process in ISO/IEC, called "stabilization" for 
putting aside an obsolete standard.  You essentially say that you will no 
longer do maintenance on it, neither corrigenda nor technical revision, 
and it is removed from the SC work program. 

> I presume that a PAS submission for ODF 1.2, say, would be viewed as a 
> ISO/IEC Standard and not just a maintenance of IS 26300.  I am guessing
> about that.  If it were to be IS 26300:2009, say, I think it would not 
> presumed to obsolete 26300:2005 either way.

It is common for PAS (and Fast Track) standards to have future versions 
submitted as "technical revisions".  I've certainly seen some submitted 
with language stating that it cancels and replaces previous versions.  I 
don't know if we would do that, but I've certainly seen it happen.  See 
Ecma C# Programming Language, for example.  The second edition (ISO/IEC 
23270:2006) carries the following note in the Forward:

"This second edition cancels and replaces the first edition (ISO/IEC 
23270:2003), which has been technically revised."

> I am assuming that for the foreseeable future, ODF 1.x Standards do not
> supplant any of their predecessors.  This assumption is consistent with 
> handling of other standards for (interchange) formats, since the formats 
> be long-lived whether or not there is active development and interest in
> extended versions.  (I notice that XML 1.0 is about to go to edition 5,
> although there is a complaint about substantive changes in that one.)
> Finally, from my position of ignorance of the ins-and-outs of the PAS
> process and the OASIS relationship with ISO/IEC JTC1, I would think that 
> alignment of this kind would be viewed as a positive step in carrying 
> PAS-submitter responsibilities for maintenance. 
> It would certainly make our maintenance work more straightforward. 
Having a
> common errata for ODF 1.0 and ODF 1.0ed2 would also make much more sense
> (since almost all items will apply to both specifications), and the 
> for clarifications from SC34 and IS 26300:2006 adopters would be greatly
> facilitate.

There are really two questions, and I think we should consider the first 
one carefully:

1) What maintenance work should we be doing?
2) And what will make that work easier?

The question of what work we should be doing is a question for this TC and 
this TC alone.  JTC1/SC34 does not set our maintenance priorities.  We are 
not agents of SC34.  We own the maintenance of ODF, the vendors, users and 
other parties represented on this TC.  (And I should say that our TC 
roster includes 7 members of SC34, so they should feel free to speak up as 
well).  In terms of my single vote on the TC, I will not be casting it to 
spend time and effort on making additional trivial editorial changes to a 
version of ODF that is not implemented by any member of the TC, nor dare I 
say by any member of SC34.

Of course, we need to respond to defect reports submitted by SC34, and do 
so in a timely and courteous fashion.  But we are not obligated to make 
any change to any particular version of ODF based purely on these defect 
reports.  Responding to a defect report does not automatically mean 
creating another errata document.  That is one possible response.  Another 
possible response is to state that we will apply the fixes directly and 
only to ODF 1.2.  That is at our discretion.

You express concern for clarifications by ODF adopters.  I share this 
concern.  But I note that in processing the SC34 defect report, which as 
you've seen largely consists of trivial editorial comments, we have passed 
over dozens of publicly submitted comments on our comment list.  We've 
taken the SC34 defect report out of turn and have since then delayed 
responding to early submitted public comments, many of which have raised 
more substantial questions than the SC34 defect report.  So I am concerned 
that we are taking time to replace "A" with "An" and "the the" with "the" 
when more significant issues, some reported by you yourself, remain 
unacknowledged and unprocessed on the public comment list.


> -----Original Message-----
> From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
> Sent: Thursday, October 16, 2008 10:29
> To: office@lists.oasis-open.org
> Subject: RE: [office] ODF_1.0_Errata_4h - Adjustments
> What if we pulled this item altogether from the draft errata document 
> fixed it in ODF 1.2 only?  What is the downside?  Is the underlying 
> such that the continued presence of the defect in ODF 1.0 (and ISO/IEC 
> 26300) will present substantial practical difficulties to an implementor 

> or to other users of the standard? 
> If not, I'd remove this item from the document.  We can then approve 
> we all agree on and give this item more consideration and possibly add 
> to a future errata document.  Maybe it would fit better on an ODF 1.1 
> errata document?   This is certainly within our rights as a TC.  And 
> ISO/IEC process allows a "Further consideration required" response to an 

> item in a defect report, so such a decision (provided we approve the 
> remaining items in a timely fashion) should be acceptable.
> -Rob
> From:
> "Dennis E. Hamilton" <dennis.hamilton@acm.org>
> To:
> <office@lists.oasis-open.org>
> Cc:
> <patrick@durusau.net>, <Michael.Brauer@Sun.COM>
> Date:
> 10/16/2008 12:34 PM
> Subject:
> RE: [office] ODF_1.0_Errata_4h - Adjustments
> Michael to answer your question:
> 1. To make the comparable change in the OASIS Standard ODF 1.0, we would 

> need to make changes in most of the section to have it become the same 
> the section in IS 26300 (with its errata changes).  That is because of 
> title, the use of URI where IRI is wanted, and to provide correct 
> instructions.
> 2. We can do that.  My recommendation for doing that is to have a 
> 17.5 erratum that only changes The OASIS Standard section, in addition 
> he one that only changes the IS 26300 section.  To attempt to accomplish 

> all of that in one erratum where the changes required are quite 
> seems simply unworkable to me. 
> 3. I had hoped to avoid that work so we might avoid another discussion 
> about substantive changes *and* to deal with the SC34 defect report.  It 

> is my understanding that the SC34 defect report is not about the OASIS 
> Standard ODF 1.0.  It is about IS 26300:2006.  What we are stumbling 
> is the fact that this is a place where IS 26300 and OASIS ODF 1.0 are 
> different and can't be resolved against the defect report using 
> corrections.
> That is my thinking. 
> 4. I see no technical problem with making the change to align OASIS ODF 
> 1.0 with IS 26300:2006 (ODF 1.0ed2-cs1 for us), but I don't believe it 
> appropriate to attempt it by adjusting just the one paragraph in the 
> erratum as the change to IS 26300.
> 5. QUESTION: Is it appropriate and desired that we retrofit the IS 26300 

> modifications (after application of errata) to the OASIS Standard ODF 
> specification via the errata? 
>  - Dennis
> PS: I don't know the answer to the question.  I'm concerned that it is a 

> substantial matter.
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
> http://lists.oasis-open.org/archives/office/200810/msg00078.html
> Sent: Thursday, October 16, 2008 03:39
> To: dennis.hamilton@acm.org
> Cc: office@lists.oasis-open.org; patrick@durusau.net
> Subject: Re: [office] ODF_1.0_Errata_4h - Adjustments
> Dennis,
> On 10/16/08 08:22, Dennis E. Hamilton wrote:
> http://lists.oasis-open.org/archives/office/200810/msg00077.html
> [ ... ]
> > 
> > 3. I changed the paragraph to be replaced to have the IS 26300 text, 
> the ODF 1.0 text.
> The errata is an errata for ODF 1.0. I therefor think it does not work
> to have only the ISO 26300 text here, because this simply does not exist
> in the ODF 1.0 document for which we provide the errata.
> I have no objections to providing the ISO 26300 in addition to the ODF
> 1.0 text.
> > 
> > 4. I indicated that the change is not to be made only to IS 26300 and 
> not to OASIS ODF 1.0.
> > 
> > This becomes an accurate change for IS 26300:2006.  The change is not 
> needed for OASIS ODF 1.0.
> But we are creating an errata for ODF 1.0, not ISO 26300. The only
> reference to RFC2396 is the one in section 17.5. We do not get
> inconsistent if we replace that with a reference RFC3986 and RFC3987. We
> did that for ODF 1.0 2nd edition already.
> Why don't we just update the ODF 1.0 specification by the errata to what
> we have in ODF 1.0 2nd edition/ISO 26300 anyway, of cause with applying
> the additional errata we are discussing here? The only thing that was
> missing is an additional reference to RFC3987.
> [ ... ]
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]