[uddi-spec] Errata, Committee Specifications, and OASIS Standards

[William Cox <william.cox@bea.com>]

I've checked the OASIS procedures and considered how they apply to the
evolution of v2 and v3.  Quotations are from the OASIS Committee Process
document, dated September 16, 2002 [
http://oasis-open.org/committees/process.shtml ], and from the OASIS TC
Guidelines, updated to reflect the current Committee Process [
http://oasis-open.org/committees/guidelines.shtml ]. The questions I
researched were about errata/corrigenda on the path from an OASIS
Committee Specification to an OASIS standard. I'll use UDDI v3 which is
currently a Committee Specification.

bill cox

SUMMARY

These are my recommendations, and are not intended to represent the
positions of the UDDI-spec TC, OASIS, or anyone else.

v3 is a Committee Specification right now.  A collection of errors and
corrections (errata and corrigenda) are being built up. The editors may
do drafts that reflect those changes and comments.  When the TC wants to
publish a version as "completed and approved work of the TC," it should
be identified with a version number (the next should probably be UDDI
v3.1), and approved by vote of the TC. Note that there MUST be a 30 day
public comment period mediated by the uddi-comment list before moving on
to an OASIS Standard. Multiple public reviews are encouraged, and
probably useful, but I don't think that a public review is useful  until
a stable v3-amended is produced. (This review is a prerequisite for the
OASIS Standard procedure.)

The original intent of the TC seemed to have been to leave v3 alone and
create a v4 with new work of the committee; we've discussed this is
previous email and meeting minutes.  Spec version numbers are owned by
the TC; whether updates to v3[.0] are considered in the v3.x path or a
v4.x path are up to the committee.  Again, the apparent intent of the TC
is to do some significant work on v3.x, followed by work on v4.x.

I recommend that we work toward v3.1 as a publicly reviewed Committee
Specification, and at the conclusion of that public review decide
whether another revision cycle is needed, or move v3.1 toward OASIS
Standard.

INCIDENTAL QUESTION ON TRADEMARKS/SERVICEMARKS

"The name of a Committee Specification may not include any trademarks or
service marks not owned
by OASIS."

Are the (potential) trademarks/service marks "UDDI"  and "Universal
Description, Discovery, and Integration" marks now owned by OASIS? If
not, our first Committee Specifications are already in violation of
OASIS procedures.

SUPPORTING DETAILS

My comments/notes are not in quotation marks.

From the TC Guidelines:

"*Flexible The OASIS TC process allows multiple entry and exit points as
well as flexibility in
deliverables. Proposals to start new TCs require only certain minimum
information; broad
scope is allowed in what the TC work will be. The TC can complete its
work with a Committee
Specification, approved by the TC, or can additionally get OASIS member
ratification for the
spec by having it approved as an OASIS Standard." [part of bullet list
of benefits of OASIS]

A Committee Specification is intended to be "completed and approved
work:"

"The Committee Specification is the completed and approved work of the
TC; the individual members
of the TC vote to approve the work at this level. A Committee
Specification is work-complete, and
people and organizations may start implementing it without having to
wait for OASIS Standard
status, but the approval of the specification by OASIS members gives
additional credence to the
spec. There is no requirement that the TC also submit the Committee
Specification for consideration
as an OASIS Standard."

Given the discussions on evolution of v3, it seems clear that v3 is not
"work-complete," and probably should have been maintained as an internal
draft until the current modifications are complete and a clean point is
reached. Recovery from this is in my summary above -- make v3.1 the next
"work-complete" version, do a public review, and consider moving to
OASIS Standard.  We can also say that UDDI v3.1 is complete without
choosing to move to OASIS Standard - we should consider this choice at a
later date.

In the OASIS Standard process,   "Errata or Corrigenda to a submission
are not permitted; if changes are required the Committee Specification
must be withdrawn by the TC, edited, re-approved as a Committee
Specification, then resubmitted."

A similar process does not appear to apply to a Committee Specification,
but my interpretation is that the time series of Committee
Specifications must be complete documents without lists of errata or
corrigenda attached. Intermediate drafts are permitted (and are commonly
done) to reflect the work of the TC.

"Before the TC can submit its Committee Specification to OASIS
membership for review and approval as an OASIS Standard, the TC must
conduct a public review of the work. The decision by the TC to submit
the work for review requires a majority vote. The review should be
publicized on applicable OASIS mail lists and other public mail lists.
Review must take place for a minimum of 30 days, during which time no
changes may be made to the document. Comments must be collected via the
TC’s public comment list. The TC must record the comments received as
well as the resolution of those comments. The TC may conduct any number
of additional review cycles (i.e. collecting comments, making edits to
the specification, sending out a revised version for review again, etc.)
before deciding that the review is complete. After the conclusion of the
review and final changes to the document, the TC must re-approve the
work as a Committee Specification before submitting it to OASIS."

A public review of a Committee Specification must be done before
submission as an OASIS Standard; the review SHOULD be publicized, be at
least 30 days long, and comments MUST be collected via the uddi-comment
list. Final changes must again be approved as a Committee Specification.

Attachment: william.cox.vcf
Description: Card for William Cox