Re: ODF 1.0 Maintenance + Synchronizationof OASIS:ISO/IEC

[robert_weir@us.ibm.com]

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

> 
> NEW QUESTION
> ------------
> 
> This must have been considered and I apologize for revisiting old 
analysis,
> but I am curious if the current maintenance and incoming avalanche of
> defect-report items justifies another look:
> 
> 1. IS THERE ANY TECHNICAL OBSTACLE TO PROCESSING 
OpenDocument-v1.0ed2-cs1 AS
> AN OASIS STANDARD?
> 

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. IF WE CAN DO IT, WHY IT MIGHT BE A POWERFUL IMPROVEMENT FOR 
MAINTENANCE
> AND SC34 SYNCHRONIZATION:
> 
>    2.1 The idea would be to process Second Edition CS1 without changes 
(no
> applied errata) and go through the pain of an OASIS Standard ballot 
process
> 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 
OASIS
> 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 
up
> with ODF comments and with defect reports from SC34.  Comments and 
defect
> submissions involving substantive changes would be deferred up-level to 
an
> 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 
of
> 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 
divergence. 

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 
you.

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 
this.


> 3. KEY ASSUMPTION
> 
> I am operating under the assumption that ODF 1.0 versions will continue 
to
> have overlapping lives and are generally intended to be upward 
compatible,
> 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 
new
> 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 
be
> 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 
the
> handling of other standards for (interchange) formats, since the formats 
may
> 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.)
> 
> 
> 4. SOAP BOX
> 
> 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 
an
> alignment of this kind would be viewed as a positive step in carrying 
out
> 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 
drive
> 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.

-Rob

> 
> 
> -----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 
and 
> fixed it in ODF 1.2 only?  What is the downside?  Is the underlying 
issue 
> 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 
what 
> we all agree on and give this item more consideration and possibly add 
it 
> 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 
even 
> 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 
as 
> the section in IS 26300 (with its errata changes).  That is because of 
the 
> title, the use of URI where IRI is wanted, and to provide correct 
editing 
> instructions.
> 
> 2. We can do that.  My recommendation for doing that is to have a 
separate 
> 17.5 erratum that only changes The OASIS Standard section, in addition 
tot 
> 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 
different 
> 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 
over 
> 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 
identical 
> 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 
is 
> appropriate to attempt it by adjusting just the one paragraph in the 
same 
> 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 
1.0 
> 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
> [ ... ]
> 
> > RECOMMENDATION:
> > 
> > 3. I changed the paragraph to be replaced to have the IS 26300 text, 
not 
> 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 
>