Issues with the requests for public review

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

Hi Jim,

We started work on the two ECF requests, 15-Day Committee
Specification Draft Public Review Request for OASIS LegalXML
Electronic Court Filing TC
(http://tools.oasis-open.org/issues/browse/TCADMIN-874) and 15-Day
Committee Specification Draft Public Review Request for Electronic
Court Filing 4.0 Web Services Service Interaction Profile Version 2.01
(http://tools.oasis-open.org/issues/browse/TCADMIN-875) and we have
run into some issues that I need to review with you all.

1) The approvals in the minutes simply say: "Jim Cabral has updated
ECF 4.01 core and web service SIP specifications– we need to approve
as revised committee specifications. A vote was held to approve the
revised committee specifications as noted above and the motion to
approve was passed."

I need to have the URL to the document(s) being approved in Kavi
included documentation of motions to approve working drafts for
processing and the same URLs included in the ticket. That way, anyone
who wants to follow the steps in a spec's development can connect the
dots from what the TC approved to what we ultimate publish in the
OASIS Library. Language like...

"Does the TC approve updated ECF 4.01 core (contained in
http://www.oasis-open.org/committees/download.php/45046/ecf-spec-v4.01-csprd02-jec-revisions.zip)
and web service SIP specifications (contained in
http://www.oasis-open.org/apps/org/workgroup/legalxml-courtfiling/download.php/45045/ecf-v4.0-webservices-v2.01-csprd02-jec-revi)
as Committee Specification Drafts and further approve releasing them
for public review? A vote was held to approve the revised committee
specifications as noted above and the motion to approve was passed."

… will meet my need perfectly and make sure that everyone can follow
what the TC has voted upon.

2) The document provided for ECF 4.01 core
(http://www.oasis-open.org/committees/download.php/45046/ecf-spec-v4.01-csprd02-jec-revisions.zip)
contains the doc file from the last public review with change control
turned on. Please in future send me final copy with all changes
accepted. I have a hard and fast rule not to touch the content
prepared by the TC so that there is never any confusion about where
changes to that content came from. If I accept all the changes and
subsequently a problem is found in the content, the question of where
the problem came from is muddied by my having touched the file.

In addition, you used the same filename as the last public review
which makes it more confusing for me to keep this copy clear from its
predecessor. Please in future use a new name with -wd## so it is
clearly labelled as a TC working draft and not a file produced by us.
E.g. ecf-spec-v4.01-wd02-jec-revisions.doc.

Last, you included a -diff.pdf, html and pdf files and some others.
Please only provide us with the editable source and other related
files (xsds, etc.) that are actually part of the specification.
Otherwise, I have to throw out files and risk throwing out something
that you intend to be part of the specification. Such as the
metadata.xml.

For this release, I will throw out the html, pdf, -diff.pdf and
~angelog.doc and assume that all the other folders and files are
intended as part of your specification. But I really don't like doing
this lest I throw out something by accident that you intended to be
included.

3) The document provided for Web Service SIP specifications
(ecf-v4.0-webservices-v2.01-csprd02.doc) appears to be identical to
the version that was publicly reviewed last October. I ran a file
compare and found no differences. Is that correct? If so, why send it
for another round of public review?

4) I need to have the the Committee Specification Draft ticket as well
as the Public Review ticket in my queue to cover both actions -
creating the csd and creating the csprd and launching the public
review.

So, to recap:

1. Please enter the Committee Spec Draft tickets for me at
http://www.oasis-open.org/resources/tc-admin-requests/committee-specification-draft-creation-upload-request

2. For ECF Core, I will accept all changes to the .doc file, throw out
the pdf, html and -diff.pdf and prepare a CSPRD for public review.
Going forward, please accept all changes and send me a finished
document and only the other component files that are part of the spec.

3. For Web Services, please let me know if there is really a need to
proceed with the public review. If the wsdl is the only file that has
changed, I don't see a need to do that.

4. Going forward, please create a new copy of the spec with a new
working draft filename and include that and associated files in your
ZIP. You don't need to create HTML, PDF or -diff files as we do that
ourselves.

5. Going forward, please include the link to the URL in Kavi in your
motions when you approve work products to be processed to CSD or other
stages so that I have that connect-the-dots linkage in the public
record.

Apologies for the length of this but it has taken Paul and I both
several hours to sort this all out and I want to help you avoid any
delays in processing your requests in the future.

Please let me know if you have any questions on any of this.

Best,

/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