Version not enough? re WG4's processing of CH's DRs 08-0012, 08-0013, and 08-0014

[rjelliffe at allette.com.au]

May I suggest that a version number (i.e. whether a minor number to
accompany the major version of a changed namespace, or as a real major
number) is a ...perhaps... bureaucratic solution to a more anarchic
problem: surely if we know anything by now it is that these large schemas
always have partial support, even by the biggest players.

What I suggest instead is something like this ordered list:

<w:document
   xmlns:w="???">

   <mce:alternateContent>
      <mce:choice requires="history">

         <history:created  xmlns:history="new purl URI"
            product="MS Office 2007 SP2 Windows" as="Ecma367:2006" />
         <history:edit
            product="Open Office 4.0 Solaris"  as="IS29500:2008" />
         <history:import
            product="AbiWord 10.1 Linux"    as="ODF 1.2" />
         <history:edit
            product="MS Office 2010 Mac"  as="IS29500:2010" />

      </mce:choice>
    </mce:alternateContent>

    <w:head>...</w:head>
</w:document>

In other words, for each document type, we maintain a list that gives the
editing history of the document by product, OS, version, and format saved
(or imported). The first is the initial source. Imports/pastes can be
included too, perhaps.

This gives a much richer amount of information for a client to use to
decide how to process the document.  Looking at the last item in the list
will tell the same information as a version number would (in the @as).

Why would this be useful?

Products will always have bugs. They need to be coped with, worked around,
documented but not enshrined. Products will always have limitations and
feature differences, and even differences in interpretation of the
standard (other standards, not our esteemed editor's exacting prose of
course!)

So while we want everyone to adopt a fixed standard, in the name of
interoperability, we should not restrict the ability of products to
implement specific workarounds in order to get that interoperability.
Indeed, we should enable this kind of flexibility.

For example, lets say that an implementer of a spreadsheet function got it
wrong, and their important product acted a certain way. Having a version
number on the document root does not help this. But having the kind of
history element allows subsequent generations of the software to recognize
and silently correct documents with that problem.

This information can be used to drive under-the-hood compatibility
settings, if required. If Symphony uses a slightly different layout engine
from KOffice, then it can potentially adjust for better fidelity. If the
document comes in as ODF, then Office could decide to enable ODF's
paragraph spacing, and to persist this between saves using this mechanism.

In a way, this represents a less explicit version of "format like
WordPerfect" (or whatever it was called). But it leaves particular
workarounds and compatibility issues as the business of vendors, not of
standards bodies.

Cheers
Rick Jelliffe