Michael,
Reluctantly I have to agree that we are unlikely to agree on a
resolution for 17.5 on Monday. The amount of discussion to this point,
leaving aside all other evidence, indicates that this is a substantive
issue that will require extended discussion.
I return to the States tomorrow (I am between 5 minute "lighting"
presentations right now) and should be able to post a new version that
defers the resolution of 17.5 (to some later errata) on Sunday, October
19, 2008. (No promises of what time on that day.)
Hope you are looking forward to a great weekend!
Patrick
Michael Brauer - Sun Germany - ham02 - Hamburg wrote:
> 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"