----- Original Message -----
Sent: Wednesday, May 25, 2005 3:24
PM
Subject: [legalxml-courtfiling] Sdurham
response to others' message type comments
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