Re: [office] Comments on draft response

[Michael Brauer - Sun Germany - ham02 - Hamburg <Michael.Brauer@Sun.COM>]

Hi Dennis,

On 08/11/09 18:47, Dennis E. Hamilton wrote:
> 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.

Nothing has changed since when. But I'd like to clarify that the errata 
of cause must not normatively list text from ODF 1.0 2nd edition, but 
from the ODF 1.0 OASIS standard. That needs to be changed in the current 
draft before we can approve it as an errata.

But if we do so, where is the difference between informally listing page 
and line numbers, which may refer to a text that differs between ODF 1.0 
and ISO 26300, and listing the differing text itself?

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

Maybe this is where we have a different understanding. We as a TC can
decide what we want to include into an errata, as long as it is
non-substantive. So, even though the defect report is regarding IS
26300, we anyway can improve the language we have in ODF 1.0. The 
proposed resolution does not just revert the text to ODF 1.0 (in that 
case, we indeed would get a problem). It changes the text of both ODF 
1.0 and ISO 26300. We therefore may include it into an ODF 1.0 errata.

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

There may be other definitions in ODF 1.0 that we can make clearer. 
Actually, I've clarified some of them in ODF 1.2 part 3. For
instance, I have replaced the resolution of relative IRIs by an
algorithm, and have stated what the relation is between the
manifest:full-path attribute and the file names used in the Zip file. If 
you have proposals how to further clarify this or other things, please 
let us know.

But in the ODF 1.0 erratas we prepare we are in the first place trying 
to resolve that issues that have been reported by SC34. There are a few
regarding section 17.5. I think we should address these, knowing that we
add additional clarifications to ODF 1.2.

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

I prefer JIRA for this purpose. We had many notes in part 1, but 
imported all these into JIRA later.

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