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] Motion for approving ODF 1.2 as Committee Draft and submittingit for pubic review.

"Andreas J. Guelzow" <andreas.guelzow@concordia.ab.ca> wrote on 06/11/2010 
04:15:07 PM:

> > In that context, it means OpenDocument Format as in a file format. The 

> > other possible choices being PDF or HTML.
> There are various (related) file formats referred to as ODF: ODF 1.0 and
> ODF 1.1 comes to mind, with ODF 1.2 in process. I am specifically asking
> which version.
> And if the answer is ODF1.2 I obviously have some issues with that since
> there is only a moving target with that name.

The requirement on the OASIS side is "the TC must explicitly designate one 
of those delivered formats as the authoritative document".

Note that "authoritative" is not explicitly defined, but presumably it 
means that if there is a difference among the HTML, PDF and ODF versions, 
that the ODF version is considered correct.

It should be clear that there are at least two ways for these format 
versions to differ:

1) Versions generated from the ODF version, such as the PDF and HTML 
versions, may have differences introduced in them during the conversion 
process.  We have seen in the past, with ODF and with OOXML as well, cases 
where the PDF version had errors not present in the original source. Ditto 
for HTML.

2) Any of the formats may exhibit differences when viewed by different 
editors/viewers.  This is obviously true in the ODF version, but also true 
with HTML version.  However, I have not seen any reports of PDF 

Now, if I were Lord of OASIS, and wanted to indicate an authoritative 
version of a specification, I would do one of either:

a) Fully specify the reading environment of the document, e.g., the 
application, the operating system, the page size, the installed fonts, 
etc.  As we know, even the same word processor can render differently 
depending on the environment.

b1) Allow publication only in standardized formats, where the standards 
have full conformance tests which guarantee perfect interoperability, and 
say that the spec is only authoritatively read when read in an application 
that 100% passes the conformance tests.

b2) Like b1, but manually validate by visual comparison that the PDF or 
HTML versions do not differ in any substantial way from the presentation 
of the ODF version.

But no one has given me these powers, and even if they did I'm not sure 
this ideal approach would be of much help.

In the end our choices are limited to:

1) Choose the ODF document as the authoritative document.  This has the 
advantage, when viewed in the same editor, of being closest to what the 
editors actually wrote and saw.  It has the disadvantage of not being an 
approved standard.

2) Chose the PDF or HTML versions.  These formats are standards (though it 
is unknown whether our posted versions conform 100% with the ODF and HTML 
standards).  In one sense they are more interoperable, in terms of 
app-to-app variation.  But if they differ from the editor's intent, then 
I'm not sure that really matters.

So I don't see any perfect choice here.  Any OASIS TC needs to make a 
decision on this consideration, and whether you pick the editable source 
or a derived/generated version, there are opportunities for surprises. 



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