OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Re: [office] ODF_1.0_Errata_4h - Adjustments

    Posted 10-17-2008 08:26
    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" 


  • 2.  Re: [office] ODF_1.0_Errata_4h - Adjustments

    Posted 10-17-2008 12:13
    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" 


  • 3.  RE: [office] ODF_1.0_Errata_4h - Adjustments - Removing 17.5

    Posted 10-17-2008 17:04
    Michael, I agree with removal of any correction for the relative-path and
    RFC-referencing paragraph.
    
    I don't think it is necessary to delete the replacement for the "All other
    kinds of IRI references ..." paragraph, but I will accept whatever version
    that Patrick puts up on Sunday, October 19.
    
    Here is an important reason for the "All other kinds of IRI references ..."
    statement.  I don't believe it adds any restriction that is not already in
    17.5.  If some of those restrictions are undesirable, 17.5 needs a different
    kind of repair and/or deprecation or extension in ODF 1.2.
    
    WE SHOULD KEEP THIS IN MIND FOR 1.2
    
    RATIONALE:
    
       1. The last sentence of the original "All other kinds of IRI references
    ... " is "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."
    "Return ... into another one" would appear to be restrictive, depending how
    one might interpret "return." - Is this only meant to prevent some kind of
    mutual cross-reference?
    
       2. The observation about "special processing" is too much about what an
    implementation might do and the resources that a host system might make
    available.  The preceding paragraph (which is intact in this regard) makes
    it clear that the effective base IRI must be realized by some means.  I
    believe this is authoritative and the "special processing" observation is
    both too specific and not necessary.  (They also use more terms that are not
    used in the IRI specification itself.)
    
       3. The first paragraphs and the bulleted-item list at the beginning of
    17.5 makes it clear to me that the counter-example is not permitted in
    accordance with ODF 1.0:
    
    "The following restrictions exist for IRIs that are used within a package:
    ...
    
    "   * IRIs that reference a sub file of a package shall be relative, and
    they shall not contain paths that are not within the package.  This
    especially means that sub files of a package shall not be referenced by an
    absolute IRI. [It does not restrict this to the same package in any way.
    --dh:]
    
    "   * sub file[s] of a package cannot be referenced from outside the
    package, for instance from the file system or another package."
    
    It seems to me that the change did not introduce a new issue but simply
    reflect in a direct way the constraints that are already expressed in 17.5.
    I do agree that the issue needs to be dealt with if this is an unintended
    consequence of 17.5 as it is already written.
    
     - Dennis