RE: [office] Errata: Substantive Schema Change in 15.27.22?

[Doug Mahugh <Doug.Mahugh@microsoft.com>]

In general I agree with your point, Andreas, but since this was corrected to "style:wrap-dynamic-threshold" in ODF 1.1, it seems to me that reverting to the typo of version 1.0 in ODF 1.2 may be confusing to implementers.

FYI, we have not implemented this attribute in Word, because Word doesn't have the option to specify a minimum distance with dynamic wrapping.  So our particular implementation is not affected by the resolution, regardless of which approach is used.

Regards,
Doug


-----Original Message-----
From: Andreas J. Guelzow [mailto:aguelzow@math.concordia.ab.ca]
Sent: Monday, September 22, 2008 11:35 AM
To: office@lists.oasis-open.org
Subject: Re: [office] Errata: Substantive Schema Change in 15.27.22?

On Mon, 2008-09-22 at 12:54 -0400, robert_weir@us.ibm.com wrote:

> The OASIS's Approved Errata process says:  "Once approved, the Approved
> Errata shall be with the specification it corrects, in any publication of
> that specification."
>
> Of course, it is possible that someone creates a new implementation based
> on a pre-errata version of ODF 1.0 that they downloaded a year ago.
>
> But the intent is:
>
> 1) The TC's work should be thoroughly reviewed before submitting it for
> approval at Committee Specification and above.
> 2) That, combined with the 60-day public review at Committee Specification
> stage, should find any critical technical flaws in the text.
> 3) Once approved as an OASIS Standard, we can fix minor (Not Substantive)
> errors via the Errata process
> 4) But if some more serious technical flaw is found, especially one that
> would require modifying existing conformant implementations,  it should be
> fixed in a new version of the standard.
>
> Note that a new version does not necessarily mean ODF 1.2.  If we found a
> set of critical technical errors in ODF 1.0, we could always make an ODF
> 1.01 version and send that through the approval process.  I'm not
> recommending this, but that is the route for dealing with changes that
> impact conformance.

Perhaps one should then stick with the intent: the missing "h" is
clearly not a "serious technical flaw" but changing the spec would
impact on any implementation.

So I really see no reason to confuse things by making that change (I
intentionally do not say "correction").

Andreas


---------------------------------------------------------------------
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