OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsdm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Clarification on Errata



I would like to make one other clarification on the Errata here:

The WSDM TC explicitly voted NOT to ask for changes in the Standard currently being voted on.  The specification being voted on stands as is.

We did decide to follow typical OASIS processes and have our specifications identify where an errata document, if any, would be posted. just like WS-Reliability, WS-Security specifications and other OASIS standards.  In fact, the MUWS specifications being voted on already have that reference in the title page.


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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]