ECF 4.1: Distinctions between Core and SIP Specifications (REVISED)

["Price, Jim" <JPrice@courts.az.gov>]

ECF TC,

 

After mulling over the conversation associated with ECF 4.1 log entries 26 (NDC) and 27 (NFRC) during the last TC meeting and deciding where best to place certain pieces of information relative to ECF “Core” Specification and the Service Interaction Profile (SIP) specifications (plural), it would be helpful to distinguish their purpose and value.  The following is provided for your consideration:

 

1. The ECF “Core” Specification defines "WHAT" must be done – keeping in mind various message exchange possibilities.  Examples:
1. A “singular” submission (i.e., RvFR) associated with and destined for specific court and case.
2. A “bulk” submission that may include multiple “Core” Filing Messages and one Payment Message associated with and destined for a specific court and case.
3. A “bulk” submission that may include multiple “Core” Filing Messages and one Payment Message associated with a specific court and multiple cases.

 

The "WHAT" defines the ECF message cardinalities permitted for a given message exchange (e.g. RvFR, NDC, NFRC) and their relative order within ECF messages.  The “WHAT” is technology agnostic.

 

2. The SIP Specification defines "HOW" message exchanges (e.g., RvFR, NDC, NFRC) are to be performed based on a specific technical implementation.  A SIP is not technology agnostic, i.e., a SIP specifies the implementation of a given technology such as web services, IBM MQ, etc.  However, the SIP’s message payload is technology agnostic because it is governed by the ECF “Core” Specification, which defines message cardinality.  In brief, message cardinality is technology agnostic, whereas SIP message exchanges are not technology agnostic.

 

A common trap (pattern) is for developers to jump to the “HOW” before understanding the “WHAT”.  It’s human nature, particularly when definitive artifacts are misaligned in even the slightest.  Nonetheless, if the ECF TC insists on defining message cardinality and relative message order within each SIP Specification (“HOW”), it begins the process of chipping away at the purpose and value of the ECF “Core” Specification (“WHAT”) in its entirety.

 

Recommendation 1:  Distinguish between and clarify the purpose and value of the ECF “Core” (“WHAT”) versus the SIP (“HOW”) specification documents.

 

Recommendation 2:  Revise the ECF “Core” Specification “Informative” Appendix C by adding ECF message cardinality rules and relative ECF message orders for each ECF-defined message exchange (e.g., RvFR), and make the section “Normative”.

 

Recommendation 3:  In addition to disambiguating derivatives of the words “file”, “submission”, etc., as they exist in the current specification documents, refine the definitions of the words “message” and “exchange”.  Examples:

1. ECF Message (Message): An ECF-defined XML structure designed to carry specific data values, e.g., CoreFilingMessage, PaymentMessage, RecordDocketingMessage.
2. ECF Message Exchange (Exchange):  The ECF-defined container of ECF-defined messages transmitted/shared between MDEs, e.g., RvFR, NDC, NFRC.

 

Thank you,

 

Jim