Springboard Issue 1-8 Incorrect Parameter Reference

["Graham, Gary" <GGraham@courts.az.gov>]

LegalXML ECF Incorrect Parameter Reference

 

The following issue was identified during the ECF Springboard effort:

 

I-8.  Incorrect Parameter Reference

Issue Details:

·         The provided operations tables in sections C.1.1, C.2.1 and C.3.1 each contain one instance of an operation that is defined with two “Parameters”.  The table entries, however, do not clearly identify whether the parameters are both optional, both required or conditional.

·         After reviewing the web service definition, we discovered that the actual base parameters are defined in the WSDL and extend the “ElectronicFilingMessageType” type.  As such, the parameters column, depicted below, does not seem to properly represent the actual web service definition

Operation	Called By	Output	Parameters
ReviewFiling	Filing Assembly MDE	xsd/message/ECF-4.0-MessageReceiptMessage.xsd :  MessageReceiptMessage	xsd/message/ECF-4.0-CoreFilingMessage.xsd :  CoreFilingMessage
			xsd/message/ECF-4.0-PaymentMessage.xsd    :  PaymentMessage

Suggestion:

·         Update the tables in sections C.1.1, C.2.1 and C.3.1 to properly reflect the base types.

·         Additionally, consider moving the full type declaration from the WSDL to a message schema.

 

 

Review and Discussion

 

The following snippet is from the ECF-4.0-WebServicesProfile-Definitions.wsdl:

 

<xsd:complexType name="ReviewFilingRequestMessageType">

                        <xsd:annotation>

                                                <xsd:documentation>Multi-part message type (required for conformance with WS-I Basic Profile 1.1</xsd:documentation>

                        </xsd:annotation>

                        <xsd:complexContent>

                                                <xsd:extension base="ecf:ElectronicFilingMessageType">

                                                                        <xsd:sequence>

                                                                                                <xsd:element ref="core:CoreFilingMessage"/>

                                                                                                <xsd:element ref="payment:PaymentMessage"/>

                                                                        </xsd:sequence>

                                                </xsd:extension>

                        </xsd:complexContent>

</xsd:complexType>

<xsd:element name="ReviewFilingRequestMessage" type="ReviewFilingRequestMessageType">

                        <xsd:annotation>

                                                <xsd:documentation>Multi-part message (required for conformance with WS-I Basic Profile 1.1</xsd:documentation>

                        </xsd:annotation>

</xsd:element>

 

The suggested alternative is to define the message structures in a schema within ECF that can be leveraged by all SIPs (e.g. Web Services SIP, IBM MQ SIP, etc.).

 

This is the approach that was used for the working draft IBM-MQ SIP (see section 3 Service Definitions). The ReviewFilingRequestType is extracted and provided below:

 

<xsd:complexType name="ReviewFilingRequestType">

                        <xsd:annotation>

                                                <xsd:documentation>ReviewFilingRequestType structure for ReviewFilingRequestMessage.</xsd:documentation>

                        </xsd:annotation>

                        <xsd:complexContent>

                                                <xsd:extension base="s:ComplexObjectType">

                                                                        <xsd:sequence>

                                                                                                <xsd:element ref="core:CoreFilingMessage"/>

                                                                                                <xsd:element ref="payment:PaymentMessage"/>

                                                                        </xsd:sequence>

                                                                        <xsd:attribute ref="version"/>

                                                </xsd:extension>

                        </xsd:complexContent>

</xsd:complexType>

 

Recommendation:

 

Adopt recommendation to move operation type declarations from WSDL to XSD that would be shared by all SIPs. This will result in message consistency regardless of SIP. Clearly define in the XSD (e.g.using minOccurs and maxOccurs) if he messages are required or optional.

 

When creating standard operations XSD, consider whether the ‘complex type’ should extend ecf:ElectronicFilingMessageType (as currently done in WebServices WSDL) or if the base parameters should just be declared as a s:ComplexObjectType as proposed in the IBM-MQ SIP.

 

If extending ecf:ElectronicFilingMessageType, then the ECF specification should define how the ‘additional’ DocumentIdentification elements should be used and how this usage compares and contracts to the DocumentIdentification elements at the beginning of each ECF Message (e.g. RecordDocketingMessage, etc.).