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] ODF_1.0_Errata_4h - Adjustments


I agree. The best option we seem to have is to remove a clarification
for section 17.5 from this errata, and to resolve it in ODF 1.2. This
effects both clarifications, the one for the first paragraph, and the
one for the second. The reasons for this are below.

Patrick or Dennis: Can someone of you create a draft that does not have 
a resolution for 17.5 included? If we have an additional draft that 
contains a resolution that we may agree on on Monday, that would be okay 
for me. But we should have a draft that we can submit for public review 
on Monday even in the case that we cannot agree on a resolution for 17.5.

Regarding the resolution for 17.5: I still believe that the 
clarification for the first paragraph does work for an ODF 1.0 errata if 
it includes the changes that we have made for ODF 1.0 2nd edition. I 
further think that earlier resolutions we had for the second paragraph 
would work, too. But I did find another issue with the current 
resolution for the 2nd paragraph:

In ODF 1.0 we said:

***
All other kinds of IRI references, namely the ones that start with a
protocol (like http:), an authority (i.e., //) or an absolute-path
(i.e., /) do not need any special processing. This especially means that
absolute-paths do not reference files inside the package, but within the
hierarchy the package is contained in, for instance the file system. IRI
references inside a package may leave the package, but once they have
left the package, they never can return into the package or another one.
***

This provided the information that any other references than
relative-path references do not need any special processing. The rest
were observations. In particular, this allowed to use an IRI like
"http://www.openoffice.org/docs/mydoc.odt/content.xml"; in an ODF 
document, where "http://www.openoffice.org/docs/mydoc.odt"; is a package. 
It only said that this is not resolved as expected.

The currently proposed text is:

***
Non-relative-path references shall not refer to files inside a package.
Relative-path references having paths that traverse out of the package 
shall not reference files inside any package.
***

Applied to above IRI, this means that a document that contains this IRI
is not a valid document any more, because this IRI references some file
within another package. We therefore would declare documents that were
conforming according to ODF 1.0 to be non-conforming. That seems to be a
substantial change.

Even worse. If we apply this change to ODF 1.2, where we may of cause 
make substantial changes, we run into the following situation: When a
document was saved, "http://www.openoffice.org/docs/mydoc.odt"; did not
exist or was a directory. A document containing the IRI
"http://www.openoffice.org/docs/mydoc.odt/content.xml"; was conforming.
Later, "http://www.openoffice.org/docs/mydoc.odt"; is replaced with an
ODF package. And although nothing has changed in the document, a 
document that was conforming before suddenly isn't conforming any longer.

So, the topic seems to be far more complex than expected. For this
reason, we should not aim to resolve this in an ODF 1.0 errata. If we do
so, we should stay as close to the original text as possible to avoid
that we introduce new issues.

Best regards

Michael






On 10/16/08 19:28, robert_weir@us.ibm.com wrote:
> 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 
> 


-- 
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, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering



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