- From: Nickolas Kavantzas <nickolas.kavantzas@oracle.com>
- Date: Tue, 12 Oct 2004 16:43:22 -0700
- To: public-ws-chor@w3.org
Here is the proposal for resolving CDL issues related to WSDL (location ?). *Information Type* The new syntax of the informationType construct will be changed to: <informationType name="ncname" type="qname"? | element="qname"? exceptionType= "true|false"? /> The description would be: The attributes type, and element describe the document to be a WSDL 1.1 Message type, XML Schema type, an XML Schema element or a WSDL 2.0 schema element. Only one of these attributes MUST be used in a single informationType element. If WSDL 1.1 is used, type attribute MUST be used to refer to WSDL message type. When type attribute is defined, it can also refer to a simple or complex XSD type. For WSDL 2.0 message types, only the element attribute MUST be used. When exceptionType attribute is "true", this type is an Exception Type and could map to WSDL fault type. Since WSDL 2.0 supports unique faultnames, the element attribute in the informationType refers to a WSDL 2.0 faultname when exceptionType is "true". By default, this attribute is "false". *Fault Support* WSDL Faults are described using informationType with attribute exceptionType=true. An example of the informationType description for a fault type is given below: <informationType name="OutOfStockExceptionType" element="wsd:OutOfStockFault" exceptionType="true" /> Where element attribute value "wsd:OutOfStockFault" could point to unique fault name in a WSDL 2.0 based definition. *Example WSDL 1.1 and fault mapping in CDL* WSDL operation definition: Note that in the below WSDL 1.1 definition, the fault badPOFault is of type POBadAckMsg. <wsdl:portType> <wsdl: operation name="handlePurchaseOrder"/> <wsdl:input name="poInput" message="POMsg"/> <wsdl:output name="poAckOutput" message="POAckMsg"/> <wsdl:fault name="badPOFault" message="POBadAckMsg"/> </wsdl:operation> </wsdl:portType> WS-CDL mapping of the fault: WSDL 1.1 does not have unique fault names. In the below CDL snippet, we create a unique fault type "badPOFault" and map its type to POBadAckMsg in WSDL file above. <informationType name="badPOFault" type="wsd:POBadAckMsg" exceptionType="true"/> *Example WSDL 2.0 and fault mapping in CDL* WSDL operation definition: In the below WSDL 2.0 definition, the fault badPOFault is of type POBadAckMsg. <wsdl:interface name="pohandling"> <fault name="badPOFault" element="ghns:POFaultMsg"/> <wsdl: operation name="handlePurchaseOrder"/> <wsdl:input name="poInput" message="POMsg"/> <wsdl:output name="poAckOutput" message="POAckMsg"/> <wsdl:outfault ref="badPOFault" messageLabel="out"/> </wsdl:operation> </wsdl:interface> WS-CDL mapping of the fault: WSDL 2.0 allows the definition of unique fault names. In the below CDL snippet, we create a fault type "badPO" and map it to WSDL fault badPOFault <informationType name="badPO" type="wsd:POFault" exceptionType="true"/> *Message Parts* The following change is to be done to support WSDL 1.1 parts: The syntax of the tokenLocator construct is: <tokenLocator tokenName="qname" informationType="qname" part="identification"? query="XPath-expression"? /> The following needs to be added in the CDL document section 2.4.3 The attribute part defines the document part from which the query has to be done if this is a WSDL1.1 document. Otherwise this attribute is invalid. *Changes to the WS-CDL function getVariable()* The following change is to be done to support WSDL 1.1 parts: xsd:any* getVariable(xsd:string varName, xsd:string part, xsd:string documentPath, xsd:string roleName?) Returns the information of the Variable with name varName as a node set containing a single node. The second parameter part specifies the message part of a WSDL1.1 document. For a WSDL 2.0 document it MUST be empty. When the third parameter documentPath is empty, then this function retrieves the entire document from the Variable information. When it is non-empty, then this function retrieves from the Variable information, the fragment of the document at the provided absolute location path. The fourth parameter is optional. When the fourth parameter is used that the Variable information MUST be available at the Role specified by roleName. If this parameter is not used then the Role is inferred from the context that this function is used. *MEPS* WS-CDL supports today One-way and Request/response MEPs. This is sufficient to support BP1.1. The MEPs supported for WSDL 2.0 (per Charlton's recommendation) are: · In Only · Robust In Only · In-Out *WSDL 2.0 Interface Inheritance* An interaction happens on a channel of channelType that has a behavior which specifies a WSDL 2.0 interface. If this interface is inherited from another interface, then WS-CDL interactions can use this channel to call operations of the base interface as well. Regards, Nick
Received on Wednesday, 13 October 2004 01:04:42 UTC