When is an OASIS change too substantive to be handled in an Errata?

Dennis E. Hamilton dennis.hamilton at acm.org
Thu Mar 25 20:12:08 CET 2010


In the 2010-03-17 initial teleconference of SC34 WG6, there was a brief
discussion of two questions:

 1. Which changes in DCOR1 are sufficiently material to be carefully
examined and understood?

 2. When is a change to an OASIS document too substantive to be handled in
an Errata?

Here are my personal answers to these questions, in reverse order:

 2. NON-SUBSTANTIVE CHANGES PERMITTED IN OASIS ERRATA

 2.1 The basic determinant that an errata makes no significant substantive
change is the ODF TC's certifying that there are none when submitting an
errata to public review.  For example, in submitting the ODF 1.0 Errata CD04
document to Public Review, the submission to the TC Administrator
constituted an ODF TC attestation that no substantive changes are being
introduced.

 2.2 The yardstick that the ODF TC is to have applied is determination that
none of the changes in the Errata would/can impact a conformant
implementation.  (See 3, below, for a tricky case we dealt with.)


 1. THE MOST-MATERIAL CHANGES IN THE OASIS ODF 1.0 APPROVED ERRATA 01 (and
Part 1 of the Errata 01 CD04).  

This is my classification.  You can inspect these in the change-marked
document I recently posted about,
<http://mailman.vse.cz/pipermail/sc34wg6/2010-March/000062.html>


You can also scan the 26300/DCOR1 proposal or the ODF 1.0 Errata 01 CD04
which replicates these in its Part 1.

  1.1 ODF 1.0 section 6.7.5 Display: N0942:40 responses (two places) on
explanation of text:display attribute values and which are effective where.

  1.2 ODF 1.0 section 9.2.19 Glue Points, Align sub-heading: N0942:48
response (the first change in that sub-section).

  1.3 ODF 1.0 section 9.3.3 Objects, Object Data sub-heading: N0942:60
response, the third erratum under 9.3.3 (might surprise someone with objects
represented by single XML documents that really don't need an ODF package
sub-document to hold them)

  1.4 ODF 1.0 section 9.3.11, Common Image Map Attributes and Elements
sub-heading: N0942:04 change to URL from URI. (Stays IRI in 26300 though not
sure why, since one would presumably want an IRL for the same reasons as URL
in OASIS ODF 1.0.)  The change appears to limit the value to ones that are
potentially resolvable to resources.

  1.5 ODF 1.0 section 15.10.1 Row Height: N0942:97 response on
style:min-row-height attribute is probably benign but could alter expected
(but still compliant?) behavior.

  1.6 ODF 1.0 section 15.11.9 Border Line Width: N0942:98 response on cell
borders, not page borders, was probably not misunderstood before since the
attributes are specifically about table-cell properties.

  1.7 ODF 1.0 section 15.27.22 Dynamic Wrap Threshold: N0942:91 response
changes the name of an attribute in the ODF 1.0 schema. ****************
(see 3, below)

  1.8 ODF 1.0 section 15.27.31 Wrap Influence on Position: N0942:95
resolution, apart from a grammar agreement problem, depends on a subtle
distinction between the use of overlie/overlay and overlies/overlays.  It is
not clear which "overly" was intended to be and whether the difference
between overlay and overlie as a term of art in publishing layout would be
misunderstood in the first place.

  1.9 ODF 1.0 section 15.30.4 Chart Symbol Size: N0942:87 resolution might
have problems depending on whether the text or the schema is believed.

  1.10 ODF 1.0 section 15.31.4 Tickmarks: N0942:79 resolution.

  1.11 ODF 1.0 section 16.1 Data Types, length custom data type: N0942:74
resolution might have zero be unexpected by an implementation, perhaps?

  1.12 ODF 1.0 section 17.7.6 Key Derivation, Key Derivation Name
sub-heading: N0942:69 resolution

  1.13 ODF 1.0 Appendix B, [DOMEvents] reference: N0942:39 response.st

3. CHECKING FOR NO HARM

The change to the ODF 1.0 schema in 15.27.22 (item 1.7, above) was a concern
for me, since we were speculating that developers would assume
style:wrap-dynamic-treshold is a misspelling and use
style:wrap-dynamic-threshold instead.  I was not so sanguine about that,
considering use in non-English contexts and the fact that there is nothing
about XML that has Namespace local names have to correspond to natural
language terms used in their explanation.  They certainly are not meant to
be translated, as I think is well-understood.

As part of the development of Errata 01 and its CD01-CD02 public review
drafts (CD03 became the Approved Errata 01), we polled the implementations
we knew about.  I also put requests on some mailing lists.  Because this is
an open, public standard, it seemed to me we could not know about all of the
implementations, especially by developers who do not participate on the ODF
TC or in other public forums about ODF.

The best information I could come up with was a private report from one
implementer saying that the attribute is not implemented in their product
and any spelling will be ignored. I also learned from the ODF Translator
project on SourceForge that they had never seen either attribute in ODF
documents they had analyzed.

And, since it is already style:wrap-dynamic-threshold in the ODF 1.1 schema
sort of settles the matter (although style:wrap-dynamic-treshold could have
been allowed as a deprecated alternative).

 - Dennis










More information about the sc34wg6 mailing list