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

Robert, that's an interesting question/suggestion.

I think the reason for the change in the IRI-specific paragraph was to deal
with path-relative reference being part of the URI syntax but the term is
not used in the IRI syntax (which appears to use "rootless" instead).  The
current reference to section 6.5 of [RFC3987] is not completely informative
(although it has some important elements, especially considering how all
segments of an IRI are not necessarily treated the same, something that can
happen for in-package paths and paths that leave the package).  It is
probably not a giant problem but Murata-san found the change to be agreeable
in discussions with Michael.  (Of course, Murata-san is only paying
attention to IS 26300, etc.)

We could avoid that change (for now) since it is technically not a fix that
works directly for the ODF 1.0 OASIS Standard.  Also, there is an item in
the new list of defects that will raise the issue again.


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:



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

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.

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


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


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


"Dennis E. Hamilton" <dennis.hamilton@acm.org>
<patrick@durusau.net>, <Michael.Brauer@Sun.COM>
10/16/2008 12:34 PM
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 

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 

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


On 10/16/08 08:22, Dennis E. Hamilton wrote:
[ ... ]

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

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:

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