[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-courtfiling] Groups - ECF 4.1 and 5.01 document cardinality.docx uploaded
Gary,
I also considered the cardinality of ServeFiling and CoreFilingMessage and came to the same conclusion. It is not necessary to align the cardinality of ServeFiling and the ReviewFilingRequest as they are invoking different MDEs.
I'm not aware of anyone identifying the fact that ServeFiling does not include a PaymentMessage as an issue before. The scope of ECF includes fees and payments to the court (and EFM), not necessarily any third parties involved in service. If we do decide
to add support for payments to ServeFiling, we'll also have an issue with payment receipts as we haven't defined an asynchronous response to ServeFiling. Does anyone else think
this juice would be worth the squeeze?
From: Graham, Gary <GGraham@courts.az.gov>
Sent: Thursday, June 29, 2023 12:21 PM To: Jim Cabral <Jim.Cabral@infotrack.com>; legalxml-courtfiling@lists.oasis-open.org <legalxml-courtfiling@lists.oasis-open.org> Subject: RE: [legalxml-courtfiling] Groups - ECF 4.1 and 5.01 document cardinality.docx uploaded Jim,
I’d like to get your thoughts, and those of any TC member, on the following additional ECF v4.1 cardinality consideration:
As you know, several cardinality revisions have been made recently (see below on this thread). These changes include relaxing the cardinality for CoreFilingMessage in several requests (e.g., ReviewFiling, RecordFiling, and GetFeesCalcualtion).
I have also observed that the ServeFilingRequest only permits a single CoreFilingMessage whereas its ECF 5 equivalent ServeFilingRequest permits multiple filing:FilingMessages.
Maintaining the current cardinality limitation in ECF 4.1 for ServeFiling, e.g., allowing only one CoreFilingMessage, would require a separate ServeFilingRequest for each CoreFilingMessage for a single RvFR that contained multiple CoreFilingMessages.
Note however, that it’s the CoreFilingMessage that provides ElectronicServiceInformation (e.g., the list of recipients to be served secondary service), and especially since there is no requirement that each and every CoreFilingMessage is for the same case (i.e., may be multiple cases) in an RvFR, then a single CoreFilingMessage in a ServeFilingRequest does not appear inappropriate or unduly restrictive.
Does this makes sense or am I missing something?
Nevertheless, I also not that the ECF 5 ServeFilingRequest allows zero to one payment:PaymentMessage whereas the ECF 4.1 ServeFilingRequest does not permit any PaymentMessage. Has something been overlooked here?
Thanks
Gary Graham
From: Jim Cabral <Jim.Cabral@infotrack.com>
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
I have corrected both of these issues in WD13 which I just posted.
From:
legalxml-courtfiling@lists.oasis-open.org <legalxml-courtfiling@lists.oasis-open.org> on behalf of Graham, Gary <GGraham@courts.az.gov>
Jim,
I have now noticed an additional issue with these cardinality changes.
In the newly revised Section 5, ‘MDE Operations’, cardinality is expressed within parenthesis in the Parameters column. These will need to be corrected.
For example,
The highlighted cardinality needs to be revised to be : ‘(1, unbounded).
The above example is not the only correction that will need to be made, ReviewFiling and NotifyDocketingComplete will also require revision:
One additional thought,
Since ReviewFiling will now allow multiple CoreFilingMessages, but still only allows a single PaymentMessage, then shouldn’t GetFeesCalculation (e.g., FeesCalculationQueryMessage) also allow multiple CoreFilingMessages?
Gary
From: Jim Cabral <Jim.Cabral@infotrack.com>
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
Thanks for checking my work Gary.
During the meeting Monday, I believe there was a consensus to align document cardinality in ECF 4.1 with ECF 5.0/5.01. I doubt anyone will suggest restricting the cardinality in 5.01 to match 4.1. So, my plan is to update 4.1 with these changes and publish updated Working Drafts of both 4.1 and 5.01 now. Hopefully, that will give everyone plenty of time to review and comment on these before our next meeting July 17.
From: Graham, Gary <GGraham@courts.az.gov>
Jim,
Good analysis and I concur.
For others, the Recommendation summary in the ‘ECF 4.1 and 5.01 document cardinality.docx’ document Jim provided is easier to follow. I color highlighted the section titles below to make them stand out more. Originally I was misreading these as just a sentence continuation on the next line.
Gary Graham
From:
legalxml-courtfiling@lists.oasis-open.org <legalxml-courtfiling@lists.oasis-open.org>
On Behalf Of James Cabral
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]