OASIS Open

Oracle

No

Oracle is voting NO on the WSDM OASIS specification
ballot that is currently open.

We are fine with WSDM having TC CD status, but the spec has
dependencies on unstable specifications: WS-Addressing [1] (work in progress at [2]),
WS-Resources [3], WS-ResourceProperties [4], WS-BaseNotifications [5], WS-Topics [6],
WS-ResourceLifetime [7], and WS-ServiceGroups [8].
In addition WS-N uses a different version
of WS-Addressing than the WSDM specs do. Hence it is premature to
elevate it to the level of OASIS international specification. In
particular WS-Addressing is currently being worked on and looks like
the final version when it finally emerges will be significantly
different from its various antecedent proprietary versions. In
particular the debates and changes surrounding reference properties
and parameters will mean the use of different schema types and usage
patterns. None of these changes will mean that it can't be used by
these higher level specifications, e.g. WSDM, etc., but they will need
to be modified. The current Working Draft of the W3C WS-Addressing Working Group [2]
includes this status section:

"This is a draft document and may be updated, replaced or obsoleted by
other documents at any time. It is inappropriate to cite this document
as other than work in progress."

We think that this will set a dangerous precedent for OASIS.
Specifications that attain the OASIS international specification level
ought to be stable and have a certain amount of rigor and interop
testing. Otherwise the value of the OASIS "brand" will be diluted and
be ignored. We just don't see how that can be done in a
responsible and stable way until the underlying specifications are
mature and are themselves adopted.

We note the Committee Draft Errata Discussion [9] and we are
encouraged by this step, as it seems to validate our position.
Unfortunately it does not address our concerns for two reasons.

One: under OASIS rules:
"Errata or Corrigenda to a submission are not permitted; if changes
are required the Committee Draft must be withdrawn by the TC, edited,
re-approved as a Committee Draft, then resubmitted." [10]

Essentially that means that the TC's action have no standing or
effect on the document that is being balloted. If the TC really wishes
to implement this course of action, then under OASIS rules the current
ballot must be withdrawn.

Two: Assuming this process were followed, it would only fix one
defect, namely the normative reference to WS-Trust. It does not address the
problems with normative references and dependencies to unstable specifications; all of
which have been revised since the ballot was out.
Oracle supports the intent of the TC to
track those specifications and to make changes as appropriate to the
WSDM specifications. The inescapable conclusion is that it is premature,
at this time to elevate the WSDM specifications to OASIS specification.

In summary, it is our belief that WSDM should stay at CD until there
is more implementation experience (particularly interoperability
testing) and its dependent specifications are mature and are stable.


[1] WS-Addressing Member Submission: http://www.w3.org/Submission/2004/SUBM-ws-addressing-20040810/
[2] WS-Addressing W3C WG draft: http://www.w3.org/TR/2005/WD-ws-addr-core-20050215/
[3] WS-Resources: http://www.oasis-open.org/apps/org/workgroup/wsrf/download.php/9547/wsrf-WS-Resource-1.2-draft-01.doc
[4] WS-ResourceProperties: http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceProperties-1.2-draft-04.pdf
[5] WS-BaseNotifications: http://docs.oasis-open.org/wsn/2004/06/wsn-WS-BaseNotification-1.2-draft-03.pdf
[6] WS-Topics: http://docs.oasis-open.org/wsn/2004/06/wsn-WS-Topics-1.2-draft-01.pdf
[7] WS-ResourceLifetime: http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ResourceLifetime-1.2-draft-03.pdf
[8] WS-ServiceGroups: http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-02.pdf
[9] http://lists.oasis-open.org/archives/wsdm/200502/msg00027.html
[10] http://www.oasis-open.org/committees/process.php (section 3 b)