FYI regarding resolution to CSD and PR requests for EMIX version 1.0

[Chet Ensign <chet.ensign@oasis-open.org>]

Summary
The Energy Market Information Exchange (EMIX) committee specification
draft 03 has been created and prepared for a 15 day public review.
However, as currently loaded in the OASIS Library, the EMIX schemas do
not validate because references to the WS-Calendar schemas are broken.

After much email, conversation and consultation, I am approving a
resolution to this problem that, upon reflection (see below), does not
conform to the TC Process, specifically section 2.19, Designated Cross
Reference Changes. I am taking this action because: (a) I failed to
provide direction to the TC when specific guidance was requested, (b)
in the absence of that guidance, the TC endeavored to take what it
believed to be appropriate corrective action and (c ) the resolution
that does stay within the bounds of the TC Process establishes a
precedent in the OASIS Library that I believe to be more undesirable
than this one-time action.

This action does not establish a precedent for future TC
Administration action because it is solely due to these unique and
isolated circumstances. In particular, it does not affect the Energy
Interop committee specification request that has just been made and
where the same basic issue must be resolved. I will work separately
with the Technical Committee to appropriately fix that submission to
be within the bounds of the TC Process rules.

Resolving this issue has also raised questions about the
interpretation and application of section 2.19 of the TC Process. I
will take up these questions with the Board Process Committee and, if
a gap in our process is identified, work with them to try and close
it.

Background Facts
On June 22nd, the TC editor sent an email to the tc-admin email
address noting that the TC was preparing a work product using copies
of the WS-Calendar schemas because the WS-Calendar schemas had not yet
been published to the OASIS Library and asking, "If we vote EMIX out
of committee tomorrow, how do we handle this problem, which I would
fix now if I could, but whose proper resolution is dependent upon the
TCAdmin work schedule?" (The EMIX schemas reference the WS-Calendar
schemas.) I did not provide an answer to his question.

On June 23, a request to create Committee Specification Draft 3
(CSD03) of Energy Market Information Exchange (EMIX) specification and
to submit the draft for a 15 day public review was made to TC
Administration (TC Administration tickets TCADMIN-556 and -557). The
zip file with the specification approved by the TC included copies of
the schema files for WS-Calendar. The TC's submission ticket included
a request that "the TC Administrator insert the correct Public URIs
for WS-Calendar CSD04/PR03 [not yet released as of this request] as
they process wd35 specification and schemas for publication as EMIX
CSD03." I did not respond to the TC's  request.

On June 29, while working on CSD03, TC Admin deleted the sub-directory
containing the WS-Calendar schemas from the CSD directory structure
however TC Admin did not replace the EMIX xsd's that referenced those
copies with replacement xsd's provided by the editor that pointed to
the official WS-Calendar schemas. As a result, TC Admin produced a CSD
with schemas that did not validate.

On July 6, the TC was notified that CSD03 was loaded and asked to
spot-check them. The editor quickly notified TC-Admin that the schemas
were invalid and urgently asked that we fix them, either by replacing
the sub-directory with the copies of WS-Calendar schemas or by
replacing the EMIX schemas with provided copies that referenced the
canonical copies.

We have had numerous back and forth emails and phone calls today on
fixing this problem.

Analysis & Resolution:
Clearly, the broken schemas must be fixed before EMIX is released to
public review. Three options are available:

- Replace the sub-directory containing copies of the WS-Calendar
schemas in the EMIX xsd sub-directory, or
- Edit the EMIX schemas to point to the current versions of the
WS-Calendar schemas in the OASIS Library, or
- Replace the EMIX schemas currently in the CSD with the copies
supplied by the TC editor that point to the current versions of the
WS-Calendar schemas

Each of these comes with its own attendant pros and cons that must be
weighed in making a decision:

The first option stays within the bounds of the TC Process because we
revert to the form of the work product submitted to us by the TC.
However, it introduces a work-around that at a minimum clutters the
OASIS Library with redundant copies of work-in-progress schemas and at
worst could create confusion about what is the authoritative version
of the schema or, worse, dependencies when developers implement code
pointing to these unofficial versions of the schemas. I believe we
want to avoid creating "facts-on-the-ground" like this simply to stay
within the letter of the law.

The second option flies in the face of the rule that TC Administration
does not touch the actual content of specifications beyond a very
limited number of changes specifically listed in the TC Process. This
is critical to ensuring the integrity of the OASIS process and
certifying that that contents of a specification are the approved work
product of the Technical Committee and no one else.

The third option violates the letter of the TC Process by replacing
one part of a work product with another. The TC Process is abundantly
clear on this point. In section 2.18 Work product Quality, sub-section
5 Multi-Part Work Products, it states: "Irrespective of the number and
status of the constituent parts, the Work Product as a whole must be
approved by a single Work Product Ballot" and in sub-section 6 Allowed
Changes, it states: "Any change made to a Work Product requires a new
version or revision number…" It is clear that approving a multi-part
work product, submitting it to TC Administration for official
publication and action and then sending TC Admin subsequent requests
to replace this part of it or that violates the intent of the TC
Process rules. Indeed, to allow such piece-meal changes threatens the
integrity of the OASIS process and jeopardizes the standing of our
specifications in the larger technical community.

However, in this situation, making such substitution appears to carry
the least negative and the most positive consequences. It avoids the
work-around sub-directory mess, it keeps TC Admin's keystrokes out of
the TC's content, and it corrects the EMIX schemas so that they
reference the canonical WS-Calendar schemas. It is in keeping with the
intent of the TC as expressed in the approval minutes and it produces
a higher quality specification by ensuring that the proper WS-Calendar
schemas are referenced.

Therefore, I am asking the TC Admin team to replace the existing EMIX
schemas currently in the first CSD upload with the EMIX schemas
provided by the TC editor that point to the correct WS-Calendar
schemas.

At the end of the day, we want our TC's to succeed at producing
products that gain traction in their markets, recognition in their
industries, and personal satisfaction to the people who put in the
hard work to make them happen. Doing this means both helping them to
deliver the highest quality specifications to their audiences *and*
protecting the integrity and the reputation of the OASIS Process.
OASIS' reputation is a critical factor to the TC's success because it
assures adopters that our specifications are reliable and the result
of an honest, open process. With this in mind, I've not taken this
decision lightly but rather have done so in the belief that it is the
best resolution for meeting the goals outlined above.

Please let me know if you have any questions or comments.

-- 

/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-378-3472
Mobile: +1 201-341-1393

Follow OASIS on:
LinkedIn:    http://linkd.in/OASISopen
Twitter:        http://twitter.com/OASISopen
Facebook:  http://facebook.com/oasis.open