"Dennis E. Hamilton" <> wrote on 08/25/2008
03:51:53 PM:
>
> This is probably for Rob Weir and Michael Brauer.
>
> As I turn my attention to particular sections of the ODF
> specifications, I continue to notice individually-small things.
> Previously, I would have submitted them to the office-comment list.
>
> Now that I am a member of the TC, I want to know whether (1) I
> should continue to use office-comment when they are equivalent to
> what's appropriate as a -comment (so others can know that these are
> being noticed), (2) I should instead use the office list the same
> way, or (3) I need to use the proposal mechanism.
>
The OASIS policy on this stated in OASIS TC Process 2.8 "TC Visibility"
"The purpose of the TC?s public comment facility is to receive comments
from the public and is not for public discussion. Comments shall be
publicly archived, and shall be forwarded to one or more Members of the TC
including the TC Chair. TCs shall not be required to respond to comments.
Comments to the TC made by Members of the TC must be made via the TC
general email list, and comments made by non-TC members, including from
the public, must be made via the TC?s comment facility. Comments shall not
be accepted via any other means."
http://www.oasis-open.org/committees/process.php#visibility
So TC members submit comments to the TC list, while non-members submit to
the comment list. This reflects the different IP obligations involved for
members (RF with Limited Terms) versus non-members (OASIS Feedback
Licence).
The Proposal mechanism is used for feature proposals, adding new
functionality, features, etc. It is not required for simple editorial
fixes.
> Here's an example that I just stumbled upon. The optional table:is-
> data-layout-field attribute has a default value of "false" (ODF 1.1
> section 8.8.4, Is Data Layout Field sub-heading). It is defined as
> a string, not a boolean, in the schema. There is no explanation of
> how a value other than a boolean one has any significance, and I
> assume this is a simple bug, but perhaps more than an erratum is
> permitted to resolve?
>
> Or it might be worthwhile to make a comment to the appropriate list
> and then wait to see if someone says a proposal is needed?
>
My recommendation would be this:
If you, as an ODF TC member, find an error in an published version of ODF,
then:
Ask yourself: Is it a technical error or an editorial error? Will
implementors reasonably be able to figure this out? Or is it enigmatic?
Is it a typographical error? Or a real bug?
If it is a serious error, then check the existing errata documents,
published as well as draft, to see if it is already fixed. If it is not
already fixed, then post a note to the ODF TC list, reporting the bug. A
proposed correction is always appreciated. We will then add it to the
current working draft for the next errata document.
If the problem is not serious, then check the current working draft of ODF
1.2 to see if the error occurs there as well. If the error is in the
current draft, then send a note to our Editor, Patrick Durusau, so he can
fix it there. There is no need to discuss on the TC, or in a meeting
simple typographical and editorial fixes. If it is obvious what the fix
is, then sending it to Patrick is the most efficient way of handing it.
If the error is not in the current working draft, then I personally would
drop it. My inclination is not to expend energy on tracking down and
fixing minor editorial errors in ODF 1.0 or ODF 1.1. But if you
personally have an interest in doing that, then we can certainly set up a
mechanism, perhaps a spreadsheet similar to our Public Comment Registry,
for you to record such defects.
But remember, in 6 months, when we can do the next Approved Errata for ODF
1.0, ODF 1.2 will likely already be complete. Implementors have already
moved along to ODF 1.1, and some (like OpenOffice.org) have already
started the move to ODF 1.2. So the practical utility of errata for ODF
1.0 in 2009, when it is two revisions out of date, may be quite minor.
-Rob
-Rob
