OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Public Comments 214 to 256

    Posted 03-30-2009 12:20 
    Dear TC members,

I had a closer look at the public comments from 214 to 256 (unless they 
came from N-1078) and have made some suggestions how to resolve them.

We may either take this is basis for our discussions today, or we may 
continue today with 257, but agree that everyone interested in this 
matter checks the proposed resolutions until next week, where we then 
accept them as a whole.

For the future, I could imagine that we try to find volunteers that work 
out similar suggestions for other blocks of comments and post them to 
the list, where we reserve us a week to review the suggestions and then 
can accept them as a block.

Best regards

Michael

214: Proposal (for column borders)

215: Namespace URIs in ODF 1.1 specification
- The line breaks within the HTML version are a result of a line break
in the ODF variant that exists so that the URI fits into the enclosing
table cell. Appears to be too minor to correct, and may also happen in
future versions.
Resolution: none
- The space in the "number" namepsace URI is an error. Occurs in 1.0,
1.1 and even 1.2
Resolution: 1.0/1.1 Candidate for an errata
1.2: Correct URI in section 1.3

216: Incorrect reference to XSL for "length"
The reported defect is existing. The correct reference shall be to 5.11
(rather than to 5.9.11)
Resolution: 1.0/1.1 Candidate for an errata
1.2: Correct reference in chapter 17.

217: Question which document (HTML, PDF or ODF) of ODF 1.1 is the
authoritative version.
The OASIS TC process nowadays requires that one of the versions is
declared to be the authoritative document. This was not the case for ODF
1.1.
Resolution: For the future, declare ODF version to be authoritative.

218: Style names in automatic and document styles my conflict
The language has been improved for ODF 1.2 already, but does not cover 
this case.
Resolution: Add some language to 15.1 (AI for Michael)

219: is from N1078

220: classpath
The concerns regarding mentioning a Java classpath (only) seems to be 
justified. The information seems to fit better into the application 
settings:
Resolution: Remove element (this has been discussed already by the 
editors of the database proposals but did not find its way into the TC).

221: Formula SC

222: is from N1078

223: redundant paragraph
The mentioned paragraph is indeed redundant.
Resolution: 1.0/1.1 None (the redundancy does not have any impact that
seems to be worth to be corrected)
1.2: Already resolved by new structured text.


224-231: Are from N1078

232: Usage of


  • 2.  RE: [office] Public Comments from N1078

    Posted 03-30-2009 13:58 
    I am not sure why the ones from N1078 are being passed over.  They have not,
to my knowledge been reviewed in one of these discussions.  Also, my
assigning of "Candidate for Errata" was very cursory and without discussion
(and no consideration of the severity levels that were proposed since).

Can we clarify what the assumption is about what is happening with the N1078
ones and who has the action for the next step?  I think I may have it but I
have not been taking it seriously enough.  I will repent, but I want clarity
first.

 - Dennis 


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 3.  RE: [office] Public Comment #217 - Authoritative Version of Specification

    Posted 03-30-2009 13:58 
    I don't think that the easily-editable form of the specification should be
considered authoritative.  Also, because of device and implementation
differences, font substitutions, page reflow, etc., we have no control over
variations in appearance and the difficulty of associating comments and
defect reports against a fixed-form.

I recommend that the PDF be considered authoritative (and if it could be
digitally signed that would be good too).  This provides more reliable
page-chapter-verse cross-referencing and discussion in reports, submitted
defects, etc.  

 - Dennis 


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 4.  RE: [office] Public Comment #217 - Authoritative Version ofSpecification

    Posted 03-30-2009 14:27 
    On Mon, 30 Mar 2009, Dennis E. Hamilton wrote:

> I don't think that the easily-editable form of the specification should be
> considered authoritative.  Also, because of device and implementation
> differences, font substitutions, page reflow, etc., we have no control over
> variations in appearance and the difficulty of associating comments and
> defect reports against a fixed-form.
>
> I recommend that the PDF be considered authoritative (and if it could be
> digitally signed that would be good too).  This provides more reliable
> page-chapter-verse cross-referencing and discussion in reports, submitted
> defects, etc.

The technical committee is at liberty to select an authoritative format,
so the following comment (not official advice or direction from OASIS) is but
mere informal FYI -- personal comment for consideration.

I always recommend that the editable format be considered authoritative.
Here are two of the most important reasons:

1. The OASIS rule about designating an authoritative format (from among the three
    required formats (editable source, PDF, (X)HTML) arose from a concern
    that there might be a "difference" between formats, owing to document
    conversion/translation operations.  That is: conversions are sometimes
    (often) imperfect.  The notion was: if there *is* a difference, we would want
    a single point of appeal.  From this POV, it makes sense to designate the
    authoring format as authoritative, as it evidently represents the
    authoring/editorial intent.  What are the chances that the authoring
    format is "incorrect" from the standpoint of authorial intent, and that
    some derived format (the result of conversion) "correct"?  Near zero.
    If there is a difference, it's because the conversion created the difference,
    and one not representing authorial intent.

    The differences we *have* observed resulting from PDF generation and other
    conversion processes are usually small (or very small) insignificant
    changes that the human eye does not catch, because proof-readers see
    what they know must be written, not what is actually written.  That's
    why catching typos and similar mistakes is only asymptotic: several
    people acting as proof-readers will all miss the same mistake.  Now:
    why would one want a PDF (which has the typo/mistake NOT representing
    the author's intent to be authoritative?  It's a process that
    guarantees adoption of inadvertent errors -- in known classes of cases.
    Better to designate the source (the original) and not the derived
    format "authoritative".

2. OASIS allows the creation of derivative works for a range of uses,
    "without restriction of any kind."

    Official text: This document and translations of it may be copied and
    furnished to others, and derivative works that comment
    on or otherwise explain it or assist in its implementation
    may be prepared, copied, published, and distributed, in
    whole or in part, without restriction of any kind.

    Now, suppose someone does want to create an annotated (commentary)
    version, or other help system that uses the specification text
    in an online context.  We would want the creator of that derivative work
    to *start with* the authoritative format, not with some non-authoritative
    format.  If PDF is selected as authoritative, the creator of the
    derivative work would need to convert the PDF -- by some means, and all are
    known to pose serious conversion risks, and often generate artifact differences.
    (Ever try to convert PDF into editable format for such a purose?)

That's enough.  I'm quite sure Dennis has his own counter-arguments.  In
this context, the above text does not count, except as argument for the
TC's consideration.  Your game, your choice.

- Robin (speaking simply as a human being, without institutional affiliation).

-----------


>
> - Dennis
>
> 
    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 5.  RE: [office] Public Comment #217 - Authoritative Version of Specification

    Posted 03-30-2009 16:24 
    I think, as a practical matter, the defects that occur when one uses an ODF
implementation that is not the one used for the authoring are far more
disturbing than the blemishes you remark about concerning disparities in
PDFs derived from the as-authored ODF documents.  There is a problem with
the current state of interoperability for ODF consumers in comparison with
the ubiquity and stability of PDF at this point.  

The proofing-errors problems seem to apply to any renditions of the
document, although I agree it is difficult to catch those kinds of problems
when introduced in the ODF to PDF transformation and they are not stand-out
howlers. 

Signing the (authoritative) ODF version would be helpful, although we don't
know how many consumers would verify the signature, especially since it is
only being introduced with ODF 1.2 (although implemented in OO.o 2.x and
later).  Unfortunately, passing signature verification does not help us deal
with the consumer then presenting that document incorrectly, although it is
some safeguard against documents that have been inadvertently altered.  It
would be great not to get defect reports against any of those (altered or
misrendered) as reported blemishes and defects of the specification.

Note that our published errata are all against the PDF versions of the
documents because of the PDF stability advantage in this regard.  It appears
that ISO only provides PDF versions (and expects PDF submissions).  So the
risk of un-noticed defects is abated, somewhat, by the many eyes that will
eventually find them when making serious use of the material, attempting to
make translations, etc., especially if they are material defects.

Robin, thanks for raising your concerns.  It is important that we look at
the relative risks of all options.  (I have no idea what the conclusion will
be, though apparently HTML is not on the table [;<).

 - Dennis


    
                                                
    
					
                                                    

        
                                                
				
    
                                                
    
                                                    
                                                        
                                                        Original Message


  • 6.  RE: [office] Public Comment #217 - Authoritative Version of Specification

    Posted 03-30-2009 21:09 
    "Dennis E. Hamilton"


  • 7.  Re: [office] Public Comment #217 - Authoritative Version of Specification

    Posted 03-30-2009 22:11 
    Sorry, but I can't resist.

If the authoritative version of the spec is to be an XML format, then  
that would be content.xml. I don't expect that most people reading the  
spec would even *know* that there was an error in the display unless  
they were comparing two different versions, and would then have  
difficulty trying to parse out the XML itself. They would still be  
left with the question - which one is right? Particularly if one  
implementation happened to drop some XML, they wouldn't even know it  
was missing.

I agree that PDF can introduce errors, and am usually a proponent of  
the editable source as the authoritative format for the reasons Robin  
already stated.. I am beginning to think, however, that any TC using  
some flavor of OpenDocument should have to declare the particular  
tool, as I too see differences in content depending on if I look at  
the file in OO or Symphony. I don't have other OpenDocument tools  
uploaded to test, but I'm guessing some things would render  
differently depending on the tool's capabilities and conformance level.

The reality is that whatever output format is deemed by the TC to be  
authoritative, the TC must carefully review that output to ensure that  
it is accurate in all respects.

Regards,

Mary


On Mar 30, 2009, at 5:10 PM, robert_weir@us.ibm.com wrote:

> "Dennis E. Hamilton"


Related Content