Thanks Rob,
With regard to the first part, the basic categories are with regard to what
the submission says the problem is, taking into account both the text and
any classification that is provided with the submission.
I agree that these are not orthogonal and there is often a gray area (for
example, between omission and incomplete, where the latter is more likely to
be a substantive matter relating to under-specification).
I think the determination of substantive in terms of whether or not an
implementation would be impacted by resolution is a separate determination.
Part of it has to do with whether the feature has even been implemented (as
we have discovered) and also whether the more-or-less obvious simple case
and/or "do whatever OO.o does" approaches have actually prevented there
being a problem. I don't think the provisional assignment of categories can
or should deal with that, but rather be accounted for in the disposition and
the actions to determine what remedy, if any, is possible.
There is now a "Source" column in the register, although most entries are
blank and the source is the public comment list. SC34 defect-report items
are identified in the column already.
To sharpen some of these, I think I use "omission" only when the submission
says what the omission is or where there appears to be an omission.
Incompleteness is generally a submission that claims that something is
incompletely specified.
Unclear is generally when a portion of the specification is claimed to be
not understandable or just plain confusing.
Inconsistency is when the submission claims that there is a contradiction or
an inconsistency with something said elsewhere. Sometimes it may be changes
in nomenclature that might be resolved as an editorial correction (use of
the wrong or undefined term in place of the one introduced elsewhere) and
sometimes it might be something more substantial.
My general approach in this process is to take the submitter's word for it
until there is a closer examination. The important thing is I don't think
these are dispositive. That should be a separate item, which is what we say
it is, as opposed to what the main thrust of the submission is. Also, we
might concur with the identification of a problem (and when someone says
something is unclear, we should believe them), but not the suggested remedy,
if any.
Other matters, such as the standing of a submission and responsibility of
the TC to have a response of some sort is something I would like to keep
orthogonal to characterization of the substance of a submission (as opposed
to the import of that after review, disposition, and action).
- Dennis
PS: As far as I am concerned, all comments from external sources, unless
clearly capricious, are meritorious at any time and under all conditions. I
think there should be a transparent process for their disposition, with the
decision to go forward, take action, or simply let them sit made explicit.
(Although it does not happen often, it does happen that SC34 errata point at
something that already arose elsewhere, including within the TC or an
earlier public comment from other submitters.) It is one of the things that
distinguishes open efforts such as OASIS TC, W3C comment handling, and of
course IETF technical committee conduct.
PPS: With regard to discussion on the public comment list, it is pretty
clear when that is happening, including when the discussion is between the
submitter and TC members. I have not added those to the list beyond the
original submission which was directly to the list and not any subsequent
on-list discussion. Sometimes the discussion may lead to retraction and
sometimes there is a proposed disposition (e.g., some adjustment in an
OpenFormula definition). I would think closing out the original submission
involves finding out what has actually been done in the specification, just
as we need to regression-check 1.2 against previously-accepted comments and
any errata based on them.
Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
http://lists.oasis-open.org/archives/office/200901/msg00120.html
Sent: Sunday, January 18, 2009 09:12
To: dennis.hamilton@acm.org
Cc: Michael Brauer; ODF TC List; Patrick Durusau
Subject: [office] Re: Categories for Public Comment and Defect-Report Items
"Dennis E. Hamilton"