Action Item 2004-07-01 Solution to 168/R114

Folks,

Below please find my action item completed. (I did not want to receive 
friendly reminders from Jonathan every day during 4th of July ;-)).

Here is my position on the thread started with David [1]. The questions 
I was trying to answer and my position wrt those are:

(1) should WSDL require identifying the operation name? (yes)
(2) should WSDL enable identifying the specific mechanism that makes the 
operation name known? (yes)
(3) should WSDL provide a way to operation name regardless of the 
mechanism employed? (yes)
(4) should WSDL define the mechanism of implementation? (no)

This proposal addresses 1, 2 and 3 as an addition to Part 1. My earlier 
proposals addressed all
of the above (see [2] and [3]) in the past and there are similar 
elements in my current proposal, but given that there are different ways 
to do (4) and we will never agree on it, at least I am hoping that we 
agree that we should at least be able to agree to identify them in a 
WSDL document.
In essence, the proposal below is in the spirit of Hugo's email [4], but 
also requires that all extensibility mechanisms to be declared in WSDL.

If there are "friendly"  amendements or spec-eze improvements, please 
send them. I realize that there may be additional rules one may be able 
to formulate for satisfying the OperationName feature other than those 
stated, but this will not break the intention of the proposal, namely 
WSDL is the contract and all dependencies must be declared.

Cheers,

[1] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jun/0300.html
[2] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jan/0082.html
[3] http://lists.w3.org/Archives/Public/www-ws-desc/2004Feb/0152.html
[4] http://lists.w3.org/Archives/Public/www-ws-desc/2004Jul/0004.html


-- 
Umit Yalcinalp                                  
Consulting Member of Technical Staff
ORACLE
Phone: +1 650 607 6154                          
Email: umit.yalcinalp@oracle.com

OperationName Feature: 

This specification defines an OperationName as an abstract Feature
that is required for all WSDL documents.  OperationName Feature is
identified with the URI value:
http://www.w3.org/TR/wsdl20/features/operationName.

This Feature is assumed to be always present in the component model
and applicable for an interface operation component (See Section
2.7.1.1 Composition Model). Therefore, it is not required to be
declared in a WSDL document, but MUST always be supported. 

[Note: For sake of completeness, I propose that we identify
this feature with a URI although it will not exhibit itself in a WSDL
document]

The OperationName Feature requires the operation name to be
identifiable in a message exchange and thus be conveyed between the
requestor agent and the provider agent. Since there may be multiple
mechanisms that may implement this abstract Feature, such as other
features, binding mechanisms (i.e.  a SOAP module) or existing
extensibility mechanisms this specification does not mandate a
specific implementation. However, one the following conditions must be
met to satisfy the OperationName feature:

(1) an interface operation component must have a {style} property that
has the URI value http://www.w3.org/@@@@/@@/wsdl/style/rpc.

(2) WSDL document MUST contain a mandatory extension (see Section 8.3
Processor Conformance for the definition of a mandatory extension)
that satisfy and implement the OperationName feature. The mandatory
extension MUST be in use in a scope that contains interface operation
component (see Section 2.7.1.1 Composition Model)

[Note: I believe that it is also possible to restrict the previous
definition to binding and binding operation scopes only. I can go
either way]

This feature also defines an abstract property that holds the URI of
the name of the operation. The URI of the property is 
http://www.w3.org/TR/wsdl20/features/operationName/Name. 

Since there are different ways to implement the abstract OperationName
feature as stated above, this specification requires a unique means of
identifying the operation name via the Property value. The value MUST
be the fragment identifier that signifies the specific operation
engaged and MUST be made available in an interaction. (See Section C.2
Fragment Identifiers)