RE: [courtfiling-reqts] Comments on LegalXML System Blue Requirements -WD 04, 02/12/2005 version

[Shane.Durham@lexisnexis.com]

Rex,

Just wanted to note I have seen your extensive comments and appreciate the
work that you have put into the review.
I am very eager to discuss all of your points with you.

Of course, many of these things might be difficult to resolve through
email...
..and much easier for us to resolve in a good sit-down session.

Will you be at the face-to-face this week? 
If so, any chance that you might be arriving on Wednesday afternoon/evening?
- Shane Durham



-----Original Message-----
From: Rex McElrath [mailto:mcelratr@gaaoc.us] 
Sent: Sunday, February 20, 2005 9:11 PM
To: etingom@tsquaredinteractive.com; Shane.Durham@lexisnexis.com;
courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Comments on LegalXML System Blue Requirements
-WD 04, 02/12/2005 version

Comments on LegalXML System Blue Requirements -WD 04, 02/12/2005 version


Summary:  

Overall, the use cases are great.  A really good job has been done with
them.  My main comments are on the use of the components.  Why not use a
more bidirectional and non court receiving only approach?  For an
experiment, I went through the document and renamed some of the
components, and in doing so, a good bidirectional transaction system can
be seen in the use cases if they components are used slightly
differently.  For example, if the Assembly component and the Review
Component are seen more generally, and the "Court Record" system is seen
as a "Record System" or "Record Component":

* Sending could be done through an assembly component, for both court
and filer
* Receiving is done by a review component, for both court and filer
* Storing of the data and documents takes place in a Record Component,
for both court and filer
* Service could be a combination of a Record Component maintaining a
list of recipients and methods for contacting them, and an assembly
component that assembles either an exchange transaction or an out of
band transaction (ie - fax server, email server, mail printing) that
sends the service notices.
* Queries could be initiated by an assembly component, received by a
review component, answered by the record component, and sent back by an
assembly component to the query initiators review component.      
* Persisting data and documents could be seen as a function of a Record
Component only

The clerk could be seen as a human and/or machine that makes decisions
during the whole process, instead of solely the literal court clerk
person.  

In summary, we've got some really good work here with these use cases.
Please, push them a bit further towards data exchange and let the court
talk back to the filer.  The filer can be an entity that has a case
management system also and can go through almost the same general
procedures as the court upon receiving a document from the court.  Both
will review what is sent to them, choose to accept/reject it, choose to
store the documents and data they receive, and want to send new
documents and data to the other.

As an example of making the use cases usable for both court and other
entities and lending to both as participants in sending and receiving
communications:
Lines 124-125: "The court has accepted all of the submitted documents
and all of the relevant data in the filing into the court record.  The
court will send a response to the filer."

could read meaning either the court or another entity if stated as:

"The receiver has accepted all of the submitted documents and all of the
relevant data in the filing into a record.  The receiver will send a
response to the filer." 


Line by Line comments:

* 220-225 -  In my opinion, the filer should be able to query for fee
tables before initiating a filing, and as the filing is processed by the
receiver, the court, fee structures should be able to be assessed as an
option.  When starting a filing, a filer needs to know how much it's
going to be as an estimate, but the court should have the final option
for determining the fee structure applied when the filing is received.
In other words, the fee table query gives a good estimate of what the
expected fees are, but the clerk's office reserves the right to change
the total based on known court filing processing rules.   Since a human
may have to make the assessment or correct a machine's assessment of
fees, that is why the receiver needs to reserve the right to change the
fees applied upon receiving the filing and processing it.
* 285-292; Clerk Rejects Filing - What about an option for the sending
back a note about the rejection.  This seems to be captured in other
places.  Is this one a more high level case that doesn't need explicit
details?
* 380, 708, 880, and other lines related to "Docketing"- Docketing of
case is only a portion of the effect of exchanging information.  It
seems that the use of "docketing" should be replaced with "recording" or
other term to give the recording of the filings a more versatile use and
outcome.  Filings can produce updates, status changes, be additional
information that is entered into record but doesn't change the docket
status of the case, new motions, evidence, or etc, or in the reverse
from court to receiver the filings can be orders, notices, transfer
documents such as with an appeal, etc.
* 406-410- Notes on sending back what is recorded:  This should probably
be optional or dependent on transaction type.  The lawyer sometimes
cares what the court records about their case, but the court really
doesn't care what the lawyer does with the notices sent to them as long
as they know that the notices were received.
* 464-520- 2.8 Filer Reviews Confirmation of Completed Filing - When
does a process like this happen outside of service?  Essentially, isn't
this giving the filer review of the clerk review process?  It seems like
a query for the document could be initiated by the filer as a separate
transaction to check the content of the case data and documents to check
on the processing of the filing.  It doesn't seem like the courts
responsibility to let the filer review their data entry with each and
every filing.   This also would lead to a bit of a loop of sending back
what was sent to the court to the filer.  
* 539; Requestor Requests - May be a small bit of semantics as this is
capture during the Any Component , but what if the sentence was changed
to read, " The requestor receives the full results or the allowed
portion of their data request."
* 578-583; validation of requests- This seems like a reasonable security
process to add to pretty much all of the transactions and not just
querying.
* 599-603; Notes about requestor not valid -  This seems like a
reasonable practice.  Quick suggestion about the response to send back
about the substitution: " you're request was processed with 'public'
access rights" or something similar would be good.  People tend to think
something is wrong when they see the word "unknown" in a response from a
computer.
* 642; Filing Assembly Component Overview - Could this be rewrote as
"This component may or may not provide an interface to human Filers . .
.. ."  The Filer could have a case management system of their own and may
only interact with it.  Unless this takes that into account, in which
this will work.  At some point a human does need to interact, but
hopefully for many it will be with their own case management system and
not a separate software that just assembles and sends filings like the
old EFSP web pages do.
* 1071-1073; Get Filing List - The "filing list id" seems an awkward way
to record data unless this is like a trigger for a canned set of records
or transaction logs.   Why not use an identifier of either the filer,
the record type, conversation id's, or other descriptive to call the
list of filings?  Wouldn't the filing list ID be transient for the query
return?  I may be misinterpreting this without the background history of
the "filing list id", but wanted to make a note of this.
* 1167; Get Case list, Case List ID - Again, similar comments to those
about "filing list id" for lines 1071-1073.
* 1460-1461; Get Available Recipients - Going back to the comments in
the summary section, wouldn't a record system need to be called for the
list of recipients unless this is considered a whole separate entity
component with assembly and storage/record functions included.


Thanks,

Rex McElrath
Administrative Office of the Courts
244 Washington St. SW
Suite 300
Atlanta, GA 30334
404-657-9218
mcelratr@gaaoc.us


-----Original Message-----
From: etingom@tsquaredinteractive.com
[mailto:etingom@tsquaredinteractive.com] 
Sent: Saturday, February 12, 2005 7:36 PM
To: courtfiling-reqts@lists.oasis-open.org
Subject: [courtfiling-reqts] Groups - LegalXML Blue Requirements
(wd-LegalXML-Requirements-04.doc) uploaded

The document named LegalXML  Blue Requirements
(wd-LegalXML-Requirements-04.doc) has been submitted by Eric Tingom to
the
LegalXML Court Filing Requirements SC document repository.

Document Description:
LegalXML  Blue Requirements 

Important notes:
1.	Latest version of Blue Requirements.  

2.	I will be re-factoring several areas after the Face to Face

3.	Use Case notation will become more formal following Alistar
Cockburn
methods described in his book Writing Effective Use Cases. 

4.	I will continue to work on the Electronic Service and Court
Policy
requirements. 

5.	Please have all comments on these documents completed by
February 18th,
2005 by 5:00 p.m. -7 G.M.T.  Any comments received will then be
incorporated for the Salt Lake Face to Face.

Thank you for your participation and support of Blue

Eric


Download Document:  
http://www.oasis-open.org/apps/org/workgroup/courtfiling-reqts/download.
php/11408/wd-LegalXML-Requirements-04.doc

View Document Details:
http://www.oasis-open.org/apps/org/workgroup/courtfiling-reqts/document.
php?document_id=11408


PLEASE NOTE:  If the above links do not work for you, your email
application
may be breaking the link into two pieces.  You may be able to copy and
paste
the entire link address into the address field of your web browser.

-OASIS Open Administration


-----------------------------------------
This e-mail and any files transmitted with it are intended solely for the
use of the entity or individual(s) to whom they are addressed and not for
reliance upon by unintended recipients.  If you are not the intended
recipient or the person responsible for delivering the e-mail to the
intended recipient be advised that you have received this e-mail in error
and that any use, dissemination, forwarding, printing, or copying of this
e-mail and any files transmitted are strictly prohibited. If you have
received this e-mail in error please delete the entire email and
immediately notify us by email to the sender or by telephone to the AOC
main office number, (404) 656-5171. Thank you.