[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
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]