RE: WS SIP SOAP samples

I do not think that relaxing the wording in section 2.5 of the WebServices SIP is the correct answer.

Even though Appendix C is non-normative it is correct (the TC has discussed making it normative in ECF 5). Even though Appendix C is currently non-normative, the operation names are normative.

This issue was raised previously (see attached email). The answer you provided was:

“The names of the operations are defined in the main body of the core specification so the names are normative.”

I understand that element names consistent with ECF operation names are not defined in ECF provided schema. Hence it is incumbent upon implementers to define these in local exchange schema or perhaps in wsdl. This is the approach we have taken in Arizona working with efiling vendors.

The requirement expressed in section 2.5 (Request and Operation Invocation) goes back a long way and is unrevised since ECF 3 with the Web Services Messaging Profile 1.0 (Nov. 15, 2005). Compliant implementers would be undoubtedly harmed by such a revision. Such an approach should also harm the Test Bench ECF certification testing.

I do not think that section 2.5 was carelessly worded or mis-worded. As noted, section 2.5 states:

Each message transmission MUST identify the operation being invoked within the SOAP Body only; the (qualified) operation name MUST be the qualified name of the first child element of the SOAP body element, as called for in section 7.1 of the [SOAP 1.1] specification.

This requirement is reinforced in the referenced section 7.1 of SOAP 1.1 which provides (highlighting added):

SOAP 1.1 –section 7.1 RPC and SOAP Body:

“RPC method calls and responses are both carried in the SOAP Body element (see section 4.3) using the following representation:

A method invocation is modelled as a struct.
The method invocation is viewed as a single struct containing an accessor for each [in] or [in/out] parameter. The struct is both named and typed identically to the method name.
Each [in] or [in/out] parameter is viewed as an accessor, with a name corresponding to the name of the parameter and type corresponding to the type of the parameter. These appear in the same order as in the method signature.
A method response is modelled as a struct.
The method response is viewed as a single struct containing an accessor for the return value and each [out] or [in/out] parameter. The first accessor is the return value followed by the parameters in the same order as in the method signature.
Each parameter accessor has a name corresponding to the name of the parameter and type corresponding to the type of the parameter. The name of the return value accessor is not significant. Likewise, the name of the struct is not significant. However, a convention is to name it after the method name with the string "Response" appended.
A method fault is encoded using the SOAP Fault element (see section 4.4). If a protocol binding adds additional rules for fault _expression_, those also MUST be followed.

As noted above, method and response structs can be encoded according to the rules in section 5, or other encodings can be specified using the encodingStyle attribute (see section 4.1.1).

Applications MAY process requests with missing parameters but also MAY return a fault.

Because a result indicates success and a fault indicates failure, it is an error for the method response to contain both a result and a fault.”

If as you suggest there are only two alternatives for correction (e.g. “relax wording”, or “update schemas”) then I suggest we should pursue the latter (i.e. “update schemas”).

Gary Graham

Arizona Supreme Court

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral
Sent: Wednesday, June 10, 2015 9:17 AM
To: Graham, Gary
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] Re: WS SIP SOAP samples

Appendix C and the samples are non-normative.

I think the fix is probably to relax the wording of Section 2.5 itself since there is no schema that defines an element called “GetCase”. The alternative would be to update the schemas in the Core Specification. Do you agree?

__
Jim Cabral
502 509-4532

From: Gary Graham
Sent: ‎Tuesday‎, ‎June‎ ‎9‎, ‎2015 ‎7‎:‎20‎ ‎PM
To: James E Cabral
Cc: legalxml-courtfiling@lists.oasis-open.org

See below

From: legalxml-courtfiling@lists.oasis-open.org [mailto:legalxml-courtfiling@lists.oasis-open.org] On Behalf Of James E Cabral
Sent: Tuesday, June 09, 2015 2:54 PM
To: Graham, Gary
Cc: legalxml-courtfiling@lists.oasis-open.org
Subject: [legalxml-courtfiling] WS SIP SOAP samples

Gary,

On the TC call today, you reported an incompatibility between Section 2.5 of the WS SIP specification and at least some of the SOAP samples, including GetCaseRequest.soap. I’m hoping you elaborate more on what you see as the incompatibility. The relevant snippets are included below. Are you saying that you would expect to see “GetCaseRequest” instead of “CaseQueryMessage” inside of the soapenv:Body? No, there are no ECF operations named GetCaseRequest or CaseQueryMessage. However there is an operation named GetCase that takes CaseQueryMessage as a parameter (see C.3.1 of the ECF specification). Hence, the first child element of <soapenv:Body> MUST be GetCase since ‘GetCase’ is the operation name.

-------------------------------

WS SIP Section 2.5:

An MDE implementation MAY allow message transmissions that include a SOAPAction HTTP header.

In compliance with the [WSI-I BP 1.1] specification, a receiving MDE MAY NOT rely on the value of the SOAPAction HTTP header in processing the message.

-----------------------------

GetCaseRequest.soap:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">

<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">

<wsse:Security soapenv:mustUnderstand="1" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">

…

</wsse:Security>

<wsa:Action>urn:oasis:names:tc:legalxml-courtfiling:wsdl:WebServicesProfile-Definitions-4.0\CourtRecordMDEPort\GetCase</wsa:Action>

<wsa:ReplyTo>

<wsa:Address>https://JEC-SURFACEPRO2:8080/mockFilingAssemblyMDEPortSOAPBinding</wsa:Address>

</wsa:ReplyTo>

<wsa:MessageID>uuid:48a86134-9712-451b-a4ee-036d408b4f07</wsa:MessageID>