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" <>
To: <>
Date: Thu, 30 Jun 2005 10:23:55 -0600
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:
[mailto:]
Sent: Thursday, June 30, 2005 9:41
AM
To:
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:]
Sent: Tuesday, June 28, 2005 10:23
PM
To: Electronic Court Filing
Technical Committeee
Subject: [legalxml-courtfiling]
Record Docketing and Callbacks
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.
MTG Management Consultants, L.L.C.
(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: ''
Cc: ;
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: [mailto:]
Sent: Monday, June 27, 2005 12:04
PM
To: Cabral, James E.
Cc: ;
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
References:
RE: [legalxml-courtfiling] Record Docketing and Callbacks
From:
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
