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: RE: [wsdm] Oracle Vote


Martin, just to make sure your statement is correct. You've said [the
normative reference to WS-Trust]. The reference to WS-Trust is NOT
normative in the current Committee Draft. It is 1) contained in a
section that is explicitly said to be non normative [from the spec:
Section 5 and appendices D, E and F are normative specifications. The
rest of the document is non-normative, and is provided as a background
and explanatory material.] and 2) section 6.1 lists all normative
references of the specification and it does not include WS-Trust.

I'm not questioning your position and merely intend to point out a
possible typo on your statement.

-- Igor Sedukhin .. (igor.sedukhin@ca.com)
-- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11749

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com] 
Sent: Sunday, February 27, 2005 5:35 PM
To: wsdm@lists.oasis-open.org
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-d
raft-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-dra
ft-03.pdf
[8] WS-ServiceGroups:
http://docs.oasis-open.org/wsrf/2004/06/wsrf-WS-ServiceGroup-1.2-draft-0
2.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_workgrou
p.php.




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