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] Comments on draft response

Dennis, I'd stick to technical observations on the substance of the 
comments for now, since this particular revision is not being proposed for 
an OASIS Approved Errata ballot at this time.  Certainly, when we do have 
a vote at that stage, we'll need to fully follow the OASIS requirements 
for Approved Errata.  But right now the document is in a form that makes 
it easy for us to solicit technical review by both OASIS and SC34.  One we 
receive and incorporate such feedback, Patrick can produce the needed 
revisions to make this a proper formal OASIS deliverable.  This will 
likely not occur until after the Ad Hoc 3 meeting.    And then he'll have 
further work on the SC34 side to make it into a formal JTC1 deliverable. I 
believe he will be mindful of techniques that can be used to reduce 
unnecessary rework in that editing process.

Also, as delegates to the Ad Hoc 3 meeting, I think it is important that 
we understand the technical details on each of these issues as well as the 
TC's position on each one (where there is an  consensus).  I'm thinking of 
get an extract of the discussion in JIRA for each of these issues into PDF 
format.  I'll extract right before I head to Seattle, so I'll have the 
latest in case connectivity is sparse.



"Dennis E. Hamilton" <dennis.hamilton@acm.org>
<robert_weir@us.ibm.com>, <office@lists.oasis-open.org>, "Patrick Durusau" 
08/11/2009 12:50 PM
RE: [office] Comments on draft response


When we developed what is now Errata 01, I recall being told that we can
only issue OASIS-published errata for approved OASIS Standards.  That is 
Errata 01 consists of Errata for the OASIS ODF 1.0 Standard, and neither 
26300 nor ODF 1.0 2nd edition, which are not OASIS Standards.  (It is my
understanding that the mapping to IS 25300/ODF 1.0 2e, and the mapping to
defect-report items, was done as a courtesy but it is not the material
content of the errata document, despite how much that is all that matters 
SC34.)  If my understanding of this is correct, I would like to know what
has changed since October 2008.

1. If this is meant to be an OASIS Errata document, the disposition of
JP2-35 is inappropriate or incomplete or both.  Also, I submit that for 
OASIS ODF 1.0 Standard there is nothing to fix, at least not in terms of 
solution the defect report would like to see.

2. If this is a proposed disposition report to SC34 and is about IS 26300
(i.e., not an OASIS Errata document), then I have no problem with it 
it is not an OASIS Errata document.

3. I would have fewer concerns if this were an Errata for the OASIS ODF 
Standard, assuming that the responses work there and there is an useful
mapping to IS 26300 to satisfactorily dispose of the SC34-submitted defect

Knowing which of (1-3) or some other flavor is the case is rather 
in determining how to review the report.

 - Dennis

PS: Aside to Patrick.  In some cases, it is necessary to know the intended
end-game in order to understand how to review a working document.  I think
the level of scrutiny required is quite different depending on which case
(e.g., one of 1-3 above, or another) is intended.  It certainly governs 
much priority and energy I provide as a reviewer.  I request your
forbearance whether or not you share that concern. 

PPS: Now, I also have technical objections to the proposed solution in the
case of JP2-35, since it does not take into account other constraints that
apply and are not well-specified in the ODF specifications.  That is why I
think it is better to work this out with great care for ODF 1.2 Part 3 and
then see how to reflect that in any errata for earlier ODF 1.x standards.

I will raise my concerns in JIRA and in comments on the ODF 1.2 Part 3
working draft rather than on this thread.  FYI for background, these
concerns have to do with constraints on the Zip filename entry of a sub
file, its relationship to manifest:full-path values for that sub file, if
there is one, and other considerations around how a folder structure is
overlaid on the collection of Zip sub files for the specific purposes of 
OpenDocument Format.  To be precise about this, I say it is also necessary
to profile Zip in a way that determines what variations of Zip features 
permitted for conformant OpenDocument Format document and which ones shall
not be used.  After or along with that, one needs to say how IRI features
are reflected in the Zip filename for sub files and in the
manifest:full-path value corresponding to those sub files.  It is a
requirement of the relevant URI/IRI RFCs that such a determination be 
It could even be the case that there is no need for special 
in Zip filenames and manifest:full-path values at all since these names 
all produced via software and avoiding character-set encoding issues might
be the best approach.  If URI/IRI-encoding is provided, the considerations
need to be extended to the unique ODF manifest provisions for
manifest:full-path values (ending in "/") that project MIME types onto 
of) the ODF-defined folder structure and that do not have corresponding 
files in the Zip.  There may be more and I believe the analysis must be 
very carefully.

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Tuesday, August 11, 2009 00:14
To: dennis.hamilton@acm.org
Cc: robert_weir@us.ibm.com; office@lists.oasis-open.org
Subject: Re: [office] Comments on draft response


On 10.08.09 21:30, Dennis E. Hamilton wrote:
> Here are some problems that I notice with this approach.
>   2.2 Along with this, the JP-35 response refers to language (and 
> titles) in IS 26300 that are not the language (or referenced IETF RFCs) 

Regarding the different language: The wording of the two paragraphs in
17.5 we are talking about differs between the OASIS ODF 1.0 standard,
and the OASIS ODF 1.0 2nd edition, which is the same as ISO 26300. The
current draft lists the wording of the 2nd edition/ISO 26300. If that is
the concern, we can

a) omit the original language, and just refer to "the first paragraph
behind the list in section 17.5", etc.
b) include the text from the OASIS standard, with a note how this reads
in the 2nd edition.

Both suggestion should resolve that issue.

Regarding the different RFCs: The OASIS standard contains a reference to
5 of RFC2396. The 2nd edition/ISO 26300 contains a reference to
RFC3987, which turned out to be problematic. We are now resolving that
by a dual reference to RFC3986 (which is the successor of RFC2396) and
RFC3987. Why do you think this is an issue, in particular, since we are
not referencing RFC3986 in general, but a specific definition in a 

> the OASIS Standard for ODF 1.0.  This is no closer to resolving this one
> than when the same defect was deferred in Errata 01. 

I disagree on that. I think the issues are technically resolved, and the
editorial issue how to handle the situation that the text between ODF
1.0 and ODF 1.0 2nd edition differs should be resolvable as well.

>   I recommend that we continue to defer this item until we figure out 

I disagree on that as well. We have deferred this in the first errata
although we had a proposal how to resolve this. I don't want to defer
this one more time.

> we really want in the ODF 1.2 counterpart and then see how to reflect 
> in any future errata.

The current draft for ODF 1.2 already contains a rewrite of this
section. However, that goes in my opinion beyond what I would like to
change in an errata document.

Best regards


Michael Brauer, Technical Architect Software Engineering
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
                    D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Wolf Frenkel
Vorsitzender des Aufsichtsrates: Martin Haering

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]