Eric,
Thanks for weighing in. I actually agree with both you and Jim Price in the principle that, all things being equal, we should try to minimize the difficulty in upgrading and preserve backward compatibility even between major versions.
That said, 1) I don’t know that the TC has identified that as a governing principle and 2) a major version is our ONLY opportunity to implement non-backward compatible changes that result in improvements to the specification.
Regarding the idea of the TC providing XSLTs to convert between ECF 4.01 and 5.0, I see a number of challenges mostly due to the flexibility of ECF 4.01. In particular, while ECF 5.0 limits extensions to defined augmentation elements,
ECF 4.01 allows substitution of locally defined extensions anywhere. While it should be straightforward to provide XSLTs to map standard ECF elements between the version, it would be difficult, nay impossible, to define XSLTs that handle any extensions whatsoever.
__
Jim Cabral
502 509-4532
Jim P, Jim C,
Apologies, that I don't have time for a more carefully articulated response this week. Theoretically, I "side" with Mr. Cabral and practically I'm with Mr. Price.
I'm wondering if we could supply a set of XSLT files that could translate ECF 4.01 <-> ECF 5.0. This might allow a stepwise upgrade path instead of mandating that a court update all of its system at once. It would also force us to define that migration path
and critically evaluate the schema. It would be a ton of work, but clearly defined and we should be able to hire it out.
Anyway, I just wanted to add that I see where both of you are coming from. I'm concerned that this is going to be a difficult circle to square.
Cheers,
On Wed, Apr 19, 2017 at 8:47 AM, James E Cabral <jec@mtgmc.com> wrote:
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
>>> 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
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.
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
--
Eric Dimick Eastman
Green Filing, LLC
Cell: (765) 277-4158
|