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: "Winters, Roger" <>
To: 
Date: Thu, 30 Jun 2005 09:58:47 -0700














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

Department of
Judicial Administration

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







 









From: John M. Greacen
[mailto:]

Sent: Thursday, June 30, 2005 9:24
AM

To:


Subject: 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:
 [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,

 

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























[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [List Home]