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


Michael,

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 why
Errata 01 consists of Errata for the OASIS ODF 1.0 Standard, and neither IS
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 to
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 the
OASIS ODF 1.0 Standard there is nothing to fix, at least not in terms of the
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 because
it is not an OASIS Errata document.

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

Knowing which of (1-3) or some other flavor is the case is rather important
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 how
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 the
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 are
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 made.
It could even be the case that there is no need for special URI/IRI-encoding
in Zip filenames and manifest:full-path values at all since these names are
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 (some
of) the ODF-defined folder structure and that do not have corresponding sub
files in the Zip.  There may be more and I believe the analysis must be done
very carefully.


-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
http://lists.oasis-open.org/archives/office/200908/msg00143.html
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

Dennis,

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 section
> titles) in IS 26300 that are not the language (or referenced IETF RFCs) in

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 section?

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

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

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

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