ECF TC:
Jim Price has raised some valid questions and concerns with the scope of ECF 5.0 and the TC and in general. I have provided my responses based on my opinions and recollections but I can’t speak for the whole TC. Please take a look and
weigh in. Let’s discuss and confirm our direction at the next monthly call.
__
Jim Cabral
502 509-4532
From: Price, Jim
Sent: Tuesday, April 11, 2017 12:02 PM
To: James E Cabral;
'Harris, James'
Cc: Graham, Gary
Subject: RE: ECF 5.0 Concerns
>>> Compatibility with the latest version of NIEM is an important feature for many of our target users
Is compatibility a fait accompli? In other words, is ECF deprecating elements immediately or is there a transition period? Or are these changes optional. IMO, we should be improving upon what we have,
not replacing it for the sake of compatibility with NIEM.
>>> From my perspective, we have been fairly deliberate about the scope and schedule of ECF 5
I agree in general, but are all cards being shown on the table? Again, release notes are a deliberate communication of the things that are changing. Logs that are compiled over several years is a search-for-needles-in-haystacks
exercise.
>>> While backward compatibility is essential for minor releases (e.g. 4.01), we have been clear that major releases make no attempt at or guarantee of backward compatibility. However, I
am attempting to provide better traceability in the mappings between 4.01 and 5.0 than we provided from 3.0 to 4.0 to reduce the burden on existing implementers.
If we want to bolster interest and increase market penetration, our product should be implementable as seamlessly and as easily as possible in courts. This is the real world reality that we face today. Plug’n
Play is the norm, not the exception, but ECF isn’t even close to being Plug’n Play. Today, any changes made to the ECF specs require complementary changes elsewhere in a given court’s enterprise, e.g., CMSs, applications that operate downstream to the CMSs
(e.g., bench automation services, common case data and document repositories, interface applications to these repositories). In other words, there is a significant ripple effect throughout the enterprise from a time, effort, and cost perspectives. Backwards
compatibility should be the expectation, not the exception. This principle should never be marginalized since the courts pay the freight to implement e-filing systems. Understanding the business of the courts is critical to understanding the impact changes
to our specs have. Miss this opportunity and we miss the sole purpose for ECF’s existence. Is Arizona the only court represented in the TC…???
Regards,
Jim
From: James E Cabral [mailto:jec@mtgmc.com]
Sent: Tuesday, April 11, 2017 2:20 AM
To: Price, Jim <JPrice@courts.az.gov>; 'Harris, James' <jharris@ncsc.org>
Cc: Graham, Gary <GGraham@courts.az.gov>
Subject: Re: ECF 5.0 Concerns
Jim P,,
Any technical specfication must balance the need for new versions occasionally to address bugs and/or respond to changing requirements with the disruption upgrades can cause. Compatibility with the latest version of NIEM is an important feature for many of
our target users but certainly not the only reason for a new major version of ECF.
From my perspective, we have been fairly deliberate about the scope and schedule of ECF 5. We received feedback on ECF 4.0 and 4.01 from implementers that we were pushing out releases too frequently. We collected a list of known issues with ECF 4 and requests
for new features (e.g. scheduling, electronic service of process) and waited until NIEM 3 was released 3 years ago before starting significant development.
Now that NIEM 4 is in beta, we are actually slightly behind our ideal release schedule. I'm not saying we should rush ECF 5 but I am pushing a little harder now to keep us relevant.
Regarding your 4 princples, I think they all reflect principles we have formalized as a TC except #3 in the context of major releases like a 5.0 release. While backward compatibility is essential for minor releases (e.g. 4.01), we have been clear that major
releases make no attempt at or guarantee of backward compatibility. However, I am attempting to provide better traceability in the mappings between 4.01 and 5.0 than we provided from 3.0 to 4.0 to reduce the burden on existing implementers.
Jim H and Gary, you also have the benefit of decades on the TC. Please set me straight if I am recalling anything incorrectly.
__
Jim Cabral
502 509-4532
From: "Price, Jim" <JPrice@courts.az.gov>
Sent: Apr 10, 2017 7:16 PM
To: James E Cabral; 'Harris, James'
Cc: Graham, Gary
Subject: ECF 5.0 Concerns
Hello Jim C and Jim H,
I’m a fairly new member to the TC relative to going through a full version number release update like we’re attempting to do with ECF 5. In fact, the only experience I’ve had in this regard was the 4.0 to 4.01 update, which wasn’t a smooth
transition for Arizona (recall the cardinality issues).
It’s not clear to me what the TC’s objectives are for moving from 4.01 to 5.0. Some items we’ve discussed in depth during meetings, while other items require digging through logs to find out what else is going on, which for me is like
being on an Easter egg hunt. For instance, our mission as of late appears to be interested in NIEM compliance. This doesn’t seem like a course of action based on
business issues, but rather technical ones. From my perspective, I would expect the next full version release to take into account:
1. Providing solutions to heretofore unresolved/unaddressed business problems. We have had some ideas that we’ve attempted to pursue like Primary Service of Process, so not all is lost here.
2. Improving existing ECF 4.01 technical deficiencies associated with business realities.
3. Ensuring backwards compatibility with ECF 4.01 to mitigate cost, risk, and time-to-market concerns that could kill a project. I have no idea what the plan is behind the CaseParticipantRoleCode change, for example. Is the change simplifying our understanding of what a role is and how to better elaborate them in XML so that their meaning is unambiguous and, therefore, more easily implemented? (see #4 below)
4. Simplifying the specification so that developers AND business stakeholders can readily understand the value proposition for implementing ECF 5.
Gary, of course, has many more years of experience participating in the TC and is an incredible resource to the TC. He has called to my attention, for example, email threads that go back nearly two decades that addressed what a case participant
is. However, we seem to be veering from a direction decided long ago without fully disclosing what our mission is in this regard…at least to me. Just recently we exchanged ideas about case participant roles. You shared two files, which the Arizona Team
used to compare its one list of case participant roles. I don’t believe we landed on a course of action in this regard, but it does seem reasonable to pursue answers to specific questions, i.e., what problem are we trying to solve?
I’m not criticizing the work that’s been done, but I don’t believe that the collective ‘we’ is fully aware of what’s going on and why. Release notes, for one, should clearly state in layman’s terms what’s new in ECF 5 so that everyone
knows right up front what to expect.
My two cents.
Jim Price