Thanks Gary.
I have confirmed this version of wrappers.xsd is also valid with ECF 4.1 WD04.
Let’s discuss both versions on the next TC call and decide.
|
|
Jim Cabral |
|
Vice President, Court Relations |
|
|
502-640-4970 |
From: Graham, Gary
Sent: Thursday, August 25, 2022 12:13 PM
To: Jim Cabral
Cc: 'legalxml-courtfiling@lists.oasis-open.org';
Price, Jim
Subject: RE: ECF 4.1 Wrappers-2.xsd
Jim,
I have just returned from vacation yesterday. As promised previously, I have now completed wrappers-2.xsd (attached). Wrappers-2.xsd was created by modifying ECF 4.1 WD04 wrappers.xsd provided earlier this week. ECF 4.1 WD04 wrappers.xsd
in turn appears to be created from wrappers-1.xsd which I provided earlier this month.
With wrappers-1.xsd, three request exchanges were revised to provide a three-layered SOAP request structure, i.e., 1) Operation Name, 2) Container, and 3) ECF Message.
In wrappers-2.xsd, all request exchanges now provide a three-layered SOAP request structure.
For illustration, the GetCase SOAP using ECF 4.1 WD04 would begin as:
GetCase
<SOAP-ENV:Body>
<m:GetCase
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m0:CaseQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
This provides only a two- layered SOAP request.
Now, with wrappers-2.xsd, the following GetCase SOAP is generated:
<SOAP-ENV:Body>
<m:GetCase
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetCaseRequest>
<m0:CaseQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
This three-layered SOAP request is consistent with the three-layered requests for ReviewFiling, RecordFiling, and NotifyFilingReviewComplete provided by wrappers-1.xsd and ECF 4.1 WD04 wrappers.xsd.
Below are the additional exchanges included with wrappers-2.xsd and SOAP request generation test results:
GetPolicy
GetCaseList
GetCase
GetDocument
GetFilingList
GetFilingStatus
GetServiceInformation
ServeFiling
NotifyDocketingComplete
Tests:
GetPolicy:
<SOAP-ENV:Body>
<m:GetPolicy
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetPolicyRequest>
<m0:CourtPolicyQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetCaseList
<SOAP-ENV:Body>
<m:GetServiceInformation
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetServiceInformationRequest>
<m0:ServiceInformationQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetCase
<SOAP-ENV:Body>
<m:GetCase
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetCaseRequest>
<m0:CaseQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetDocument
<SOAP-ENV:Body>
<m:GetDocument
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetDocumentRequest>
<m0:DocumentQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetFilingList
<SOAP-ENV:Body>
<m:GetFilingList
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetFilingListRequest>
<m0:FilingListQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetFilingStatus
<SOAP-ENV:Body>
<m:GetFilingStatus
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetFilingStatusRequest>
<m0:FilingStatusQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
GetServiceInformation
<SOAP-ENV:Body>
<m:GetServiceInformation
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:GetServiceInformationRequest>
<m0:ServiceInformationQueryMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
ServeFiling
<SOAP-ENV:Body>
<m:ServeFiling
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:ServeFilingRequest>
<m0:CoreFilingMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
NotifyDocketingComplete
<SOAP-ENV:Body>
<m:NotifyDocketingComplete
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:NotifyDocketingCompleteRequest>
<m0:RecordDocketingCallbackMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
All tests pass – three-layered request SOAP requests were generated for all Request type exchanges.
Gary Graham
From: Graham, Gary
Sent: Tuesday, August 9, 2022 10:39 AM
To: Jim Cabral <Jim.Cabral@infotrack.com>
Cc: legalxml-courtfiling@lists.oasis-open.org; Price, Jim <JPrice@courts.az.gov>
Subject: ECF 4.1 Wrappers-1.xsd
Jim,
At the 8-8-2022 ECF TC meeting it was greed that I should create a full wrappers.xsd for the suggested exchange middle tier naming (e.g., rename ReveiFilingRequestMessage to ReviewFilingRequest).
When considering whether al exchanges should have equal layers (e.g., three) or whether some should only have two layers, Eric gave a favorable nod to consistency, e.g., all exchanges should have three layers
(Operation Name, Container, ECF message). I suggested that I may need to create one other additional wrappers.xsd version for equal layers.
In regard to the first assignment, I have created wrappers-1.xsd (attached). This schema version removes the name component, ‘Message’, from the element name in middle layer (e.g., Container layer), specifically
for ReviewFiling, RecordFiling and NotifyFilingReviewComplete (not needed for NotifyDocketingComplete).
Testing wrappers-1.xsd.
To test, the example implementation files provided by the WS SIP 2.01 SDK in the examples folder beneath the wsdl folder are used (e.g., FilingReviewMDE-ImplementationExample.wsdl). To test using a revised
wrappers.xsd, such as wrapper-1.xsd, requires temporary edits to the appropriate implementation example wsdl file (e.g., FilingReviewMDE.wsdl) provided by WS SIP 2.01. The schemaLocation must be revised to reference the revised wrappers schema file name:
schemaLocation="../xsd/wrappers-1.xsd"/>
then saved.
Using wrappers-1.xsd:
In the following result to SOAP > Create New SOAP request, the SOAP-ENV:Envelope is not shown:
ReviewFiling:
<SOAP-ENV:Body>
<m:ReviewFiling
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:ReviewFilingRequest>
<m0:CoreFilingMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
RecordFiling:
<SOAP-ENV:Body>
<m:RecordFiling
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:RecordFilingRequest>
<m0:RecordDocketingMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
NotifyFilingReviewComplete:
<SOAP-ENV:Body>
<m:NotifyFilingReviewComplete
xmlns:m="urn:oasis:names:tc:legalxml-courtfiling:schema:xsd:MessageWrappers-4.1">
<m:NotifyFilingReviewCompleteRequest>
<m0:ReviewFilingCallbackMessage
m1:id="ID_1"
m1:metadata="ID_1"
m1:linkMetadata="ID_1">
When testing is completed, do not forget to reverse the temporary edits made to schemaLocation in the Implementation Example wsdl files.
In my feedback, I said that NotifyDocketingComplete would need to same treatment. This was incorrect, in that NotifyDocketingComplete only contains a single ECF message (i.e., docket:RecordDocketingMessage
per wrappers.xsd), unlike the three other exchanges that have been modified in wrappers-1.xsd. I was thinking, without verifying, that it also included the PaymentMessage as does NotifyDocketingCompleteRequest.
However, when looking into this I noted that wrappers.xsd provides docket:RecordDocketingMessage within NotifyDocketingComplete as shown in the wrappers.xsd snippet below:
<xsd:complexType
name="NotifyDocketingCompleteRequestType">
<xsd:sequence>
<xsd:element
ref="docket:RecordDocketingMessage"/>
</xsd:sequence>
</xsd:complexType>
<xsd:element
name="NotifyDocketingComplete"
type="NotifyDocketingCompleteRequestType"/>
However, the ECF 4.1 specification, section C.2.1 Provided Operations (for Review Filing MDE) shows the parameter to be
RecordDocketingCallbackMessage:
|
Operation |
Called By |
Output |
Parameters |
|
NotifyDocketingComplete |
Court Docketing MDE |
xsd/message/ECF-4.0-MessageReceiptMessage.xsd : MessageReceiptMessage |
xsd/message/ECF-4.0-RecordDocketingCallbackMessage.xsd : RecordDocketingCallbackMessage |
Is not RecordDocketingMessage a parameter for the RecordFiling operation?
|
Operation |
Called By |
Output |
Parameters |
|
RecordFiling |
Filing Review MDE |
xsd/message/ECF-4.0-MessageReceiptMessage.xsd : MessageReceiptMessage |
xsd/message/ECF-4.0-RecordDocketingMessage.xsd : RecordDocketingMessage |
|
xsd/message/ECF-4.04.0-CoreFilingMessage.xsd : CoreFilingMessage |
The RecordDocketingMessage should be as parameter of the RecordFiling invocation and not of NotifyDocketingComplete.
I have made this correction in wrapper-1.xsd by modifying NotifyDocketingCompleteRequestType to be comprised of docketcb:RecordDocketingCallbackMessage and not docket:RecordDocketingMessage.
Next, I will create a wrapper-2.xsd that will provide a consistent three layers (e.g., Operation Name, Container, and ECF message) for all exchanges. Since I am about to depart on vacation, I may not have
this until later this month once I have returned.
Gary Graham