legalxml-courtfiling — archive
RE: [legalxml-courtfiling] Record Docketing and Callbacks
MHonArc v2.5.0b2 -->legalxml-courtfiling message
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Record Docketing and Callbacks
- From: "John M. Greacen" <[email protected]>
- To: "'Electronic Court Filing Technical Committeee'" <[email protected]>
- Date: Wed, 29 Jun 2005 23:53:15 -0600
|
I have reviewed Jim’s list. I believe that it is missing the “hash” of each of the filed documents. The hashes need to be part of the asynchronous Record Docketing callback and the asynchronous Review Filing callback.
I agree with Roger Winters that neither the filer nor a service recipient needs to receive “changes” made in the metadata submitted by the filer. As Roger points out, in the paper world, the docket entry(ies) made by the clerk are not communicated to the filer. If the filer is interested, the filer can check the docket. We have a query to do that. But the filer has no interest in how the clerk’s office characterizes the document on the docket. If the clerk’s office finds that the same filer is making a consistent error in the way in which s/he submits filing metadata, that is a proper subject for a telephone call or email message from the deputy clerk to the lawyer’s secretary. But there is no need for that information to be carried back to the filer in a callback message.
Similarly, the service recipient got the document(s) submitted for filing. S/he has no need to know about changes in the metadata made during the docketing process. Nor does the service recipient have a need to know the document ID number assigned by the court; s/he already has the documents themselves and does not need to access the court record to read them. We have queries to enable the service recipient to access the document in the court record if s/he loses or deletes the served documents by mistake or on purpose.
This simplifies the callbacks significantly.
From: Cabral, James E.
[mailto:[email protected]]
Everyone,
and are currently working on defining the domain models and GJXDM mappings for the Record Docketing and callbacks. In the attached email discussion of the content of each message, I identified two questions for the TC. I referenced the second issue in the "Proposed Service Model for ECF 3.0" document because it relates to the service model . But the first issue is a possible simplification of all the callbacks that I do not recall we have decided as a TC.
Again, please direct your comments to the entire TC so that we may resolve these issues as soon as possible.
thanks,
James E. Cabral Jr. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
From: Cabral,
James E. Scott,
Here's what I recall, in sequential order:
1. The ReviewFiling synchronous callback includes - the time the filing was received by the Filing Review MDE - the court-assigned case number - any error messages
2. The RecordDocketing includes - all the metadata and attached documents in the ReviewFiling message that is accepted by the clerk, as edited by the clerk - the court-assigned case number - the payment receipt
3. The RecordDocketing synchronous callback includes - the time it was received by the Court Record System - any error messages
4. The RecordDocketing asynchronous callback includes - all the metadata and attached documents in the RecordDocketing message, as modified by the Court Record System - the document identifiers for each document filed into the Court Record System - any error messages
5. The ReviewFiling asynchronous callback includes - all the metadata and attached documents in the RecordDocketing message, as edited by the Court Record System - the court-assigned case number - the disposition (accepted/rejected) of each document in the original ReviewFiling message - the document identifiers for each document filed into the Court Record System - the payment receipt (if the court processes payments) - a place for error codes
I am unclear on a couple things:
1. One simplification would be to remove the metadata and documents from the callbacks. In that case, it seems to me that we would still need to include a way to indicate to the filer what information the clerk or Court Record System changed. Or should we just say that it their responsibility to download the documents and check them for changes?
2. Another question I have is how this all relates to service. Since the service recipients receive the filing concurrently with the court, do they need to also receive notification of the changes the clerk or Court Record System make? And should the service recipients receive the document identifiers for each document? Currently, we do not have a mechanism designed to support that.
That's all I can remember. I probably missed some but it should be a good start for your strawman.
jim
From: [mailto:[email protected]] Jim, do you have an
understanding of existing consensus regarding what should go into the callbacks
and Record Docketing message structure? |
- References:
- Record Docketing and Callbacks
- From: "Cabral, James E." <[email protected]>
- Record Docketing and Callbacks
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]