RE: [legalxml-courtfiling] Record Docketing and Callbacks

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]
Sent: Thursday, June 30, 2005 9:41 AM
To: legalxml-courtfiling@lists.oasis-open.org
Subject: RE: [legalxml-courtfiling] Record Docketing and Callbacks

>> 1. The ReviewFiling synchronous callback includes

FYI: I'm going to call this thing 'MessageReceipt'.

>> - the court-assigned case number

I don't believe this value is needed in this message.

Is it supposed to represent the court's temporary/private case number, which it might briefly assign to filings which initiated a case?

If so:

What functional purpose does it serve? We have no query-interfaces, or other functions, that would make use of a court's temporary case number.

Is it a value that is relevant to a filer?

If this value is supposed to represent the court's permanent/published case number then:

If the filing is to an existing case, this value is already known to the filer and does not need to be in the MessageReceipt. If the filing is to a new case, then the value cannot be known until AFTER the filing review.

The reason I focus on this value is because it makes ReviewFiling's MessageReceipt, different than RecordDocketing's MessageReceipt.

I think our MessageReceipts, regardless of the original call, should have identical properties. I think MessageReceipt's should be consistent, regardless of what is being transmitted.

On the subject of returning docketing data to the 'Docketing' caller:

Placing my "API-designer cap" on:

I like to see function calls return the results of their function. It's just good a good technical pattern to follow (at least, I believe so). When I see functions that don't behave in that pattern, I instinctively cringe.

I think the caller of RecordDocketing, should get a callback containing a "Docketing Receipt", and that receipt should express what data was docketed, and what data was NOT docketed. That's not unrealistic, is it?

However, switching to my "functional cap":

I agree with the point of view, that it is not absolutely necessary to return those values to the caller if the following is true:

* The action of 'RecordDocketing' updates an instance of the court-record that has been made accessible, via query interface, to the FilingReview and FilingAssembly users.

Finally, with my "practical cap" on:

It has been my experience that integrated courts are unwilling to implement a query-accessible court-record.

The primary reasons are concerns about security, system strain, costs, and project deadlines. (With an underline on 'costs', and triple-underline for 'deadlines')

And so, my integration team usually relies on the 'Callback' functions to provide sufficient information about 'what was docketed' so that WE can maintain a reasonable facsimile of the court-record to be accessed by our users (both filers AND clerks).

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]
Sent: Tuesday, June 28, 2005 10:23 PM
To: Electronic Court Filing Technical Committeee
Subject: [legalxml-courtfiling] Record Docketing and Callbacks

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.
MTG Management Consultants, L.L.C.
1111 Third Avenue, Suite 2700
Seattle, WA 98101-3201
(206) 442-5010
www.mtgmc.com

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.
Sent: Monday, June 27, 2005 3:28 PM
To: 'scott@justiceintegration.com'
Cc: Tom Clarke; john@greacen.net
Subject: RE: Record Docketing and Callbacks

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]
Sent: Monday, June 27, 2005 12:04 PM
To: Cabral, James E.
Cc: Tom Clarke; john@greacen.net
Subject: Record Docketing and Callbacks

Jim, do you have an understanding of existing consensus regarding what should go into the callbacks and Record Docketing message structure?

Tom and I would like to put a strawman forward to the list on this. Can you help us build it? My recollection is that we think we need only a few data items more than what's in Review Filing...

Thanks.
--Scott

legalxml-courtfiling message