Sdurham response to others' message type comments

MHonArc v2.5.0b2 -->
















legalxml-courtfiling message






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

--

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








Subject: Sdurham response to others' message type comments




From: 
To: 
Date: Wed, 25 May 2005 14:24:40 -0700









I had some responses to others comments regarding 
the MessageType document.  I missed my opportunity to insert them into the 
agenda of the last conference call.  
 
Here they are now:
 


Case title

John indicated that a filer does not provide a case 
title as part of a filing.
 
For new case filings, LexisNexis FileAndServe permits 
the filer to express a case-title.
It serves as a default value to the clerk, and as a 
helpful-value to a filer when they are browsing their own filing history (Their 
filings retain the filer-assigned case-title until they have been accepted, 
or after they have been rejected). 
 
The clerks can, of course, change the filer-assigned 
case-title as they prepare a 'docketing' to be 
recorded.
 
I suggest that case-title be an optional part of a 
filing.
 
Also, somewhere in this discussion, John refers to 
the idea of a short-title vs. case-style.
I do not have any experience with these two distinct 
descriptors for a case.
John, can you explain the distinction a little more 
clearly (or, point me to a prior discussion of this subject)
 
Document 
Title
John indicated that document titles are not typically 
recorded in a CMS and he has suggested it should be eliminated from the 'blue' 
standard.
 
LexisNexis FileAndServe permits filers to express a 
document title and I think this has proven to be a popular feature for many of 
our courts.
 
As for integrations, I can say that 
we explicitly transmit this information as part of 
our integration with CO state and I know that they explicitly record it 
into their CMS.  We also transmit this data as part of our other 
integrations, though, I do not know whether other courts consume the data 
into their CMS.
 
Based on these experiences, I suggest that 
documentTitle should be an optional part of our 
standard.
 
ReviewFiling's Payment 
Information.
Dallas suggested that payment information should 
be optional, because not all filings require a payment.
 
It's just semantics I suppose - but, 
I would prefer to always include some kind of "payment 
information", which might or might not include a payment-instrument (it is the 
instrument which is optional, not the paymentInfo itself.).
 
Payment Information can 
indicate:
 
"I have provided no payment-instrument because I 
anticipate that none will be required.".
 
Or, 
 
"I anticipate that no payment is required.  
However, here is a designated payment-instrument which may be used in case I am 
wrong."
 

Or,
 
"I anticipate that $N will be 
required.  Here is a designated payment-instrument which may be used up to 
that amount, and no more."
 

Or, 
 
"I anticipate that $N will be 
required. Here is a designated payment-instrument which may be used up to 
whatever amount is necessary.".
 
 
DocketingID
Both Dallas and John have indicated that they see this 
value as synonymous with FilingId.
 
I think that I mildly disagree.
 
As proposed, a 'docketing' is a collection of data to 
be recorded into the court record.
It differs from a 'filing', which is transformed into a 
'docketing by the ReviewFiling process.
 
While it is true that in our present use cases, a 
docketing's data is exclusively generated by the filing process, 
if you step back for a second, you might see that 
'docketing' can be a stand-alone concept too.
 
The 'docketing' process *could* be used 
within other use cases which need to update the court record. 

So, I suggest we should not (and need not) marry 
'docketing' TOO tightly with our concept of filing.
 
I think that if we *permit* a docketing to have 
its own stand-alone concept of ID, then an implementer can choose to generate a 
docketing-specific id, or they can choose to re-use filingId.  
Either model remains available and our  
'docketing' interaction will be a little more flexible.
 
 
Scheduled Events
Dallas has indicated that he did not see 
it as a responsibility of the FilingReview component to include this scheduled 
events in 'docketing' message.
 
In my view of the process, it is 
during FilingReview that the clerk should have the opportunity to 
prepare *ALL* of the data which they want to be recorded into the court 
record as a consequence of accepting the filing.  This 
prepared data *may* include scheduled events. (I can state that our integration 
with CO state behaves in this way.)
 
However, in *some* implementations, 'scheduled events' 
(and any case data), might be generated automatically by the 
docketing process (even the simple 'permanent ID' assigned to a cases, 
documents, or parties are examples of data which is automatically 
generated by the docketing process).  This should also be ok in our 
model.
 
 

Filing Receipts, Docketing 
Receipts
I think the standard should permit (not require) a 
docketing receipt to express the court data data which was updated, modified, or 
generated by the docketing process. 
 

I think the standard should permit (not require) a 
filing receipt to express the court data data which was updated, modified, or 
generated by the FilingReview 
process. 
 
- Shane Durham
LexisNexis
 





Follow-Ups:

Re: [legalxml-courtfiling] Sdurham response to others' message type comments
From: "Dallas Powell" <>
Re: [legalxml-courtfiling] Sdurham response to others' message type comments
From: Jim Beard <>








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

--

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