Re: [office] Motion for approving ODF 1.2 as Committee Draft and submittingit for pubic review.

[robert_weir@us.ibm.com]

Mary,

If the editable format is DocBook, I think you get pretty close to my b1 
criterion.  The document is what it appears to be, because there is no 
standardized layout or rendering.  Of course, that makes it less usable 
for many.

But I'm reminded of the old saying, "In order to be able to do some things 
you must be able not to do other things".  So long as we must support 
WYSIWYG editing, then what a document "really is" will be at some level of 
indirection from what the document appears to be. 

Personally, I look at this as a "cost to conform" question.  Using a 
WYSIWYG editor and doing conformance testing by hand, with subsequent 
errors and redo's has a cost.  On the other hand, we use off-the-shelf 
familiar editors, and that results in savings.  Moving to a custom schema 
could reduce the cost of conformance testing, reduce rework, and 
accelerate specification approval cycles.  But it would have an upfront 
cost in training and tooling.

For deeply structured requirements, in many industries, we often see that 
the cost-benefit analysis leads to the use of custom XML schemas, and 
investment in tools to edit them.  But it is not clear to be that 
standards, as we define them today, has that level of structural 
requirements.  I wonder whether a middle way might be to define an 
"annotation vocabulary", maybe using RDFa to annotate a specification in 
any markup (ODF, OOXML, DITA, XHTML, DocBook).  Define URIs that indicate 
"This is the conformance clause" or "this is the previous version URL" or 
"this is the acknowledgements page".  Then you could extract a set of RDF 
triples from any specification that contain only that stuff that OASIS is 
interested in from the spec quality view.  And you could have a single 
validator that checks that.

So a pipeline of  Editable source -> RDF triples that state the "facts" of 
the specification -> validator

But of course, RDF can lie.

-Rob

Mary McRae <mary.mcrae@oasis-open.org> wrote on 06/15/2010 11:00:14 AM:

> 
> Hi Rob,
> 
>   Nice summation of the exact issues we dealt with in the Process 
> Committee. I'd love to know of any application that meets your b1 
> criteria - even PDF may render differently given the right set of 
> circumstances (I know because I have experienced and documented 
> this). If asked, I will typically recommend that a TC declare their 
> editing format as the authoritative one simply because this is the 
> one that the editors have actually worked on and hopefully is the 
> one that is reviewed by the TC and most likely to be accurate. 
> Conversions are flawed, and unless someone is going to do a b2 
> comparison (and not just visual; hypertext links can break and not 
> be spotted by a purely visual check) you can't really guarantee that
> it is 100%.
> 
>   The real answer, of course, is a single required authoring format 
> with custom conversions. But I don't think I'll ever see that in my 
> tenure at OASIS. 
> 
> Regards,
> 
> Mary
> 
> 
> 
> On Jun 15, 2010, at 10:24 AM, robert_weir@us.ibm.com wrote:
> 
> > "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 
> > differences.
> > 
> > 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. 

> > 
> > Regards,
> > 
> > -Rob
> > 
> > ---------------------------------------------------------------------
> > 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 

> > 
>