OASIS Open

Arizona Supreme Court

No

Oxford Dictionaries defines 'specification' as "an act of describing or identifying something precisely or of stating a precise requirement." By this definition, ECF 5 is not yet a specification, as it is not precise and cannot, therefore, ensure interoperability across implementations. This is admittedly an over simplification, but the TC has a grab-bag of elements that can be used any way an implementer chooses. This approach will never achieve the level of interoperability envisioned by the TC. Additionally, this approach should not be confused with the term ‘flexibility’ (“the quality of bending easily without breaking”). ECF flexibility is largely enabled through element cardinality.

The attached is a sample set of artifacts that the Arizona Judiciary developed to compensate for the level of precision wanting in the ECF 4.01 specification. The ECF specification should not require any court or vendor to develop this level of documentation just to ensure interoperability between stakeholder systems (e.g., e-filing systems, online payment systems, clerk review systems, case management systems, state bar associations, and special-purpose repositories intended to provide a level of separation between public-facing applications, like e-filing systems, from mission-critical back-office systems for performance and security purposes). Not attached is the CaseParticipantRoleCode spreadsheet recently produced by the TC.

At present, the TC is grappling with ECF 4.01-related issues that are only now being addressed. For example, CaseParticipantRoleCode values for Judges (new consideration), Attorneys, Litigants, and Other participants are being clarified, i.e., adding precision by eliminating ambiguities. Another participant role type not yet discussed within the TC is Law Enforcement. If added to the proposed ECF 5 specification, law enforcement participants would represent 1/5 of the participant types defined in the specification. Ironically, ECF is attempting to adopt NIEM elements and practices, which appears to be more in alignment with law enforcement than courts. Not to overstate the obvious, ECF stands for Electronic Court Filing. Additionally, law enforcement and courts represent two separate branches of government that have different business needs. With respect to Participants alone, a review of which elements to use (and which ones to eliminate) for each participant type must be vetted by the TC.

This same level of scrutiny should be applied to document and fee related elements. For instance, why are participant-specific element types required when associating participants to documents (e.g., FilingPartyID, FilingAttorneyID, etc.)? Shouldn’t it be enough to simply reference the entities associated with the documents without having to concern ourselves with the participant type being referenced?

For these and other reasons, I am casting a NO vote for publishing the draft ECF 4.0 WD18 for public review. In my opinion, the next iteration of ECF should have an enumerated set of value outcomes that will inspire its widespread adoption. At least one of the value outcomes that should be considered is backward compatibility.