I think everyone agrees that it is ok for a draft to depend on other
"working drafts"; Specifically, there is no issue with the WSDM 1.0 CD
depending on "working drafts" of other specifications. The issue is
whether the WSDM CD, with such dependencies, is suitable for promotion
to the level of OASIS international specification.
- Phil
Heather Kreger wrote:
Martin,
In the course of testing WSDM, of course some of the WS-RF and WS-N
specifications will be exercised.
We did ask the TC which version was appropriate to depend on and they
recommended the first 'stable draft'
from the TC.
The status sections of the WS-RF document include the following
statement:
"This document and associated schema are published by this TC as
"working drafts" and
represent the starting point for our standardization process. It is
possible that they may
change significantly during this process, but should nonetheless
provide a stable
reference for discussion and early adopters' implementations."
and WS-Notification specifications contain this in the status section:
"On 17 June 2004, this document was approved by the OASIS
WS-Notification Technical
Committee for publication so that users of the specification have a
stable draft version
available until the TC publishes a Committee Draft. Send comments to
the editor."
We believe that it was the intent of the TCs to provide a stable draft
for others to use and reference.
Committee Drafts were not (and are not) available, but a stable draft
from the TC was.
We believe that this was responsible behaviour on our part, balancing
independent timelines and
reuse of specifications available to us.
In the practical matter of interop, the versions of WS-RF and WS-N we
are using are pretty close
to those that were interop tested before submission to OASIS. We are
not tied to the interop testing
for the coming CDs, since we are not dependent on the CDs.
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>
Heather,
As part of wsdm, are you building interop tests for the ws-rf and ws-n
specs on which you depend?
I know WS-RF have an interop effort underway, but it is far from
complete at this stage. The same goes for WS-N.
I did not mean to imply that you point to the latest draft dynamically,
but even pointing to a previous working draft is not really sensible,
since such drafts have no standing whatsoever; at the very least the
dependency should be on a Committee Draft.
Martin.
-----Original Message-----
From: Heather Kreger [mailto:kreger@us.ibm.com]
Sent: 28 February 2005 21:13
To: Martin Chapman
Cc: wsdm@lists.oasis-open.org
Subject: Stable Specifications and Interoperability
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
|
|
|
To
|
|
|
cc
|
 |
|
Subject
|
|
|
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.
|
