ECF v4.1 Backward Compatibility

Electronic Court Filing Technical Committee,

When reviewing Public Feedback this prior Monday, March 20, 2023, while considering the issue of backward compatibility (see ECF 4.1 Comment Resolution Log, #15) it was concluded that ECF v4.1 was not backward compatible with ECF v4.0 and v4.01.

This was surprising, and I had thought that backward compatibility, implied by the MINOR version number increment only, would be essential.

From my review, the obstacle to backward compatibility relates to the introduction of wrappers.xsd in ECF 4.1.

If the use of wrappers.xsd is mandatory in ECF 4.1, then backward compatibility is not possible (e.g., an ECF 4.1 MDE could not process an ECF 4.01 request or response). However, when considering the requirement for the use of wrappers.xsd (see #16 in the Resolution Log) it was concluded that “wrappers.xsd is optional in the Core 4.1 specification but then required by the 4.1 Web Services SIP”.

With the optional use of wrappers.xsd in the core specification, then are there any other obstacles to ECF 4.0 and 4.01 backward compatibility?

OASIS provides Interoperability Guidelines: Interoperability Guidelines - OASIS Open (oasis-open.org)

Section 4.7 of the OASIS Interoperability Guidelines discusses Backward Compatibility provides:

4.7 Mistake #7: Backward Compatibility: it is all or nothing (and if it is not all, let us just not talk about it)

Backward compatibility: A standard is said to allow backward compatibility, if products designed for the new standard can receive, read, view or process older standards or formats. Or, it is able to fully take the place of an older product, by inter-operating with products that were designed for the older product.

Forward compatibility (sometimes confused with extensibility) is the ability of a system to gracefully accept input intended for later versions of itself. The introduction of a forward compatible technology implies that old devices partly can understand data generated by new devices.

Assume your new specification version is not backward compatible – in general, an embarrassing fact you’d prefer users to not ask about. Yet the worse thing to do is to avoid talking about it, hoping no one will notice – which may indeed be the case in the very unlikely event where everyone migrates at the same time to the new version. Users will implicitly assume backward interoperability, and they are on their way to be disappointed and angered.

Best Practice:

Describe precisely what are the non backward compatible features, and on the public relation side, explain in an FAQ why it wasn’t possible to preserve compatibility. A section describing the “diff” from V(n) to V(n+1) will greatly help implementers of the new version to understand what they can and cannot reuse from their implementation of the previous version. It may help also to specify how features of a previous version map to – have been replaced by – similar features in the new version. Now, some subset of features may still be backward compatible if not all features, and these should be identified. That will greatly help users who may actually be only concerned with these features, as well as developers who will try to architect a multi-version implementation. Describe the expected effect of using the “wrong” version when the new one (or the old one in the forward compatibility case) is handled. You might be able to define a related (and restricted) conformance profile for which backward compatibility is supported. The whole point is to honestly help users understand what can and cannot be reused from a previous implementation or environment.

For ECF, the first bullet is applicable. However, ECF is complicated by its inclusion of multiple MDEs. The words “implementations of this specification” would apply to multiple MDEs within a single ECF implementation.

When viewed this way, backward compatibility and version interoperability appear the same.

So, if the use of wrappers.xsd is optional in the core ECF v4.1 specification, then if an ECF 4.01 sending MDE, using the ECF WS SIP v2.01, provides an exchange (e.g., request) to an ECF v4.1 MDE, can the receiving MDE successfully receive and process the request?

I see nothing in the ECF v4.1 core specification that would preclude this aside from the proposed declaration (Resolution Log #15) that the two specifications are not backward compatible (and also other than the prior Web Services SIP is not listed in section 5.3 ‘Supported Service Interaction Profiles’). It appears that the only thing that may need to be done for backward compatibility is to provide direction that the use of the ECF 4.01 Web Services v2.01 SIP is allowed with ECF v4.1.

It’s not clear whether a ‘complete’ or ‘full’ ECF v4.1 system (see section 2.2 ‘Major Design Elements’) where the MDE requirements for ‘complete’ and ‘compliant’ implementations are expressed. This section does not require the use of an ECF approved SIP, however section 2.1 ‘Core vs. Profiles’ does require that “in order to be compliant, an implementation of the ECF specification MUST implement the core specification and at least one service interaction profile”. Although not stated, the presumption is that the SIP must be interoperable with the core specification and be ECF TC approved. But does this mean the SIP must be itemized in section 5.3 ‘Supported Service Interaction Profiles’?

Requiring that the SIP must be listed in Section 5.3 places a burden on the core specification. Each time a new compliant SIP becomes TC approved, then the core specification would need to be revised, reviewed, publicly reviewed, voted on, approved and then published. Of course, this core specification process could be run in parallel with the new SIP review and approval process. I would think that this is not a ‘best practice’ and that there should be a way to extend the list of recommended SIPs in section 5.3 without a full new core specification.

Recommendations:

a. Determine that the core ECF 4.1 specification is backward compatible with ECF v4.01 and state this in section 1.2 ‘Relationship to Prior Specifications’. Consider including a caveat with this statement of backward compatibility.

b. Include the ‘Web Services Service Interaction Profile 2.1 Specification’ in the listing of ‘Supported Service Interaction Profiles’ in section 5.3. This may include providing a caveat for the use of this older SIP (e.g., for backward compatibility with ECF v4.01) and a recommendation to use the new Web Services Service Interaction Profile v4.1 Specification for ECF v4.1 only implementation.

c. Consider including informative usage guidelines for the use of Web Services SIP v2.1 with ECF v4.1 either directly within the core specification or in a non-standards track work product (OASIS Defined Terms - OASIS Open (oasis-open.org)).

Possible rewording:

a. Section 1.2

Currently (beginning at line 81):

This specification does not assume that prior specifications will be deprecated. However, ECF 4.1 is not backward-compatible and applications using the ECF 3.0, 3.01 and 3.1 specifications will not interoperate successfully with applications using these specifications. This fact is indicated by the assignment of a new major version number to the ECF 4.0, 4.01 and 4.1 specifications.

Suggested rewording:

This specification does not assume that prior core specifications will be deprecated. However, ECF 4.1 is not backward compatible with the ECF 3.0, 3.01 and 3.1 specifications and applications using the ECF 3.0, 3.01 and 3.1 specifications will not interoperate successfully with applications using ECF v4 specifications, including this ECF v4.1 specification. This fact is indicated by the assignment of a new major version number to the ECF 4.0, 4.01 and 4.1 specifications.

However, applications using this ECF v4.1 specification can be backward compatible with applications using the ECF v4.01 specification provided that the Web Services Service Interaction Profile 2.1 is used when communicating between an ECF v4.01 compliant MDE and an ECF v4.1 compliant MDE. When operating in this configuration, the ECF v4.1 application MUST not utilize the wrappers.xsd for these cross-version exchanges.

b. Section 5.3, add:

• Web Services Service Interaction Profile 2.1 Specification – This specification defines a transmission system using the specifications described in the Web Services Interoperability (WS-I) Basic Profile 1.1, W3C SOAP 1.1 Binding for MTOM 1.0 and WS-I Basic Security Profile 1.1 and OASIS WS-Reliable Messaging 1.1. This service interaction profile should only be used when interfacing with ECF v4.01 applications.

c. The TC should write and approve a non-standards track guidance work product (e.g. Committee Note, see OASIS Defined Terms - OASIS Open (oasis-open.org) ) addressing the interoperable usage of ECF v4.1 and Web Services SIP v2.1.

d. Jim Price further recommends citing Section 4.7 of the OASIS Interoperability Guidelines ( Interoperability Guidelines - OASIS Open (oasis-open.org) ) within the ECF v4.1 core specification and produce a v4.1 FAQs section highlighting the specific differences between 4.01 and 4.1. These differences should make visible and justify the use of the words “backward compatibility” and “interoperability” between 4.01 and 4.1.

Gary Graham

legalxml-courtfiling message