Stable Specifications and Interoperability

[Heather Kreger <kreger@us.ibm.com>]

While we acknowledge Oracle's concern,
I wanted to express that that the WSDM 
specifications reference explicit, stable
versions of the dependent specifications. 
These versions have been through interoperability
testing. In fact, WSDM has been 
through one round of interoperability
testing on those specifications.  

WSDM is not dependent on the 'lastest
draft' from the TCs and work groups.  That would
be unstable. 

WSDM V2 will need to address the standardized
versions of these specifications. 

However, I do not see what WSDM is managing
for dependencies as any different from
what any specificaiton would need to
manage for dependencies. WSDM is depending on 
the submissions and must move to depending
on the standardized versions.  This is
precisely the same process as WSDM will
have to have when moving from depending 
on a 1.0 version to depending on a 2.0
of any specification.

WSDM will be conducting interoperability
testing. It is certainly possible to be interoperable 
before the standards status has been
obtained, look at WS-I Basic Profile.  It depends on
WSDL 1.1, which is only a W3C note,
and not a standard.  WSDM (and other OASIS specs)
depend on WS-I Basic Profile.  WS-Security
and UDDI depends on Note versions of SOAP 1.1. 
They have demonstrated interoperability
on a non-Standard specification as well. 

Heather Kreger
STSM, Web Services Lead Architect for SWG Emerging Technologies
Author of "Java and JMX: Building Manageable Systems"
kreger@us.ibm.com
919-543-3211 (t/l 441)  cell:919-496-9572

"Martin Chapman" <martin.chapman@oracle.com>

02/27/2005 05:34 PM

To	<wsdm@lists.oasis-open.org>
cc
Subject	[wsdm] Oracle Vote

Just to inform the group that Oracle has voted No
for the approval of WSDM MUWS v1.0 and MOWS v1.0
as OASIS Specifications at this point in time.

The following rationale has been provided with the
vote:

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)

_________________________________________________________________
Martin Chapman
Consulting Member of Technical Staff
Oracle
P: +353 87 687 6654
e: martin.chapman@oracle.com


To unsubscribe from this mailing list (and be removed
from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsdm/members/leave_workgroup.php.