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:
To:
Date: Thu, 30 Jun 2005 08:41:14 -0700
>>
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,
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: ''
Cc:
Tom Clarke;
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:]
Sent: Monday, June 27, 2005
12:04 PM
To: Cabral, James E.
Cc: Tom Clarke;
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
Follow-Ups:
RE: [legalxml-courtfiling] Record Docketing and Callbacks
From: "John M. Greacen" <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
