[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Record Docketing and Callbacks
Reality checking by a non-tech expert:
I THINK I agree as well. However...when, for example, the case number for a case into which the document is being filed is known, or the unique ID assigned the new filing in the existing case is being assigned during the process of receiving the E-Filing (not waiting on some later action by a reviewing or "docketing" clerk), or if the application assigns the new case's number routinely (again not waiting on a later action), it is helpful (though perhaps not mandatory) to have such details provided in the "MessageReceipt" that is created right away.
Is this an example of how we must clearly distinguish what Court Filing 3.0: 1) mandates for each and every E-Filing implementation vs. 2) recommends or endorses or suggests (as a value-adding feature) vs. 3) discourages (as a value-reducing feature) but permits, vs. 4) forbids (as something that would undermine the standard, eliminate interoperability, etc.)?
Strictly, wouldn't what is mandated plus what is forbidden be the "standard?" (Or, as we often hear, the "normative?")
Roger Winters King County Continuing Legal Education (CLE) Coordinator and Programs and Projects Manager 516 Third Avenue, E-609 MS: KCC-JA-0609 Seattle, Washington 98104 V: (206) 296-7838 F: (206) 296-0906 roger.winters@metrokc.gov
From: John M. Greacen
[mailto:john@greacen.net]
I agree with Shane that the court assigned case number is not appropriate for the synchronous callback.
I also agree that it may be useful for the court record data to be returned to the Filing Assembly MDE in the asynchronous callback. This does not change my view that no such information need be transmitted to the service recipients.
From:
Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com]
>> 1. The ReviewFiling synchronous callback includes
FYI: I'm going to call this thing 'MessageReceipt'.
>> - the court-assigned case number
On the subject of returning docketing data to the 'Docketing' caller:
Placing my "API-designer cap" on:
However, switching to my "functional cap":
Finally, with my "practical cap" on:
So, (after cycling through my decision caps) I think we DO need the ability to express court-record data in our "Docketing Receipt" and "Filing Receipt". My want of a well-formed API call, and my practical experience of NEEDING that data, makes me think we should have it.
Perhaps, the court-record data could be an *optional* part of the Callback? (I could live with that approach... which is consistent with what I deal with today).
- Shane Durham LexisNexis
From: Cabral,
James E. [mailto:JCabral@mtgmc.com] Everyone,
Tom Clarke and Scott Came 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, Jim Cabral 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: Scott Came [mailto:scott@justiceintegration.com] Jim, do you have an understanding
of existing consensus regarding what should go into the callbacks and Record
Docketing message structure? |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]