Re: [legalxml-courtfiling] Case Initiation Elements

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] Case Initiation Elements

From: "Dallas Powell" <>

To: <>,"'Electronic Court Filing Technical Committeee'" <>

Date: Tue, 31 May 2005 22:34:14 -0600

One of the assignments that Jim Cabral, Jim Harris, 
and myself were given at the New Orleans meeting was to further flush out how to 
deal with multiple documents and attachments within a single Filing Review 
Message.  This assignment relates to multiple message topics that are 
currently being exchanged.  This challenge also relates back to the Salt 
Lake discussion of the difference between a status of the Filing Review Message 
and the  of each document and associated attachments within the 
message.  

 

Here are some of the conditions that must 
be cover in the requirements and message structure:

 

For purposes of clarification to the following 
conditions here are some definitions to consider: 

 

Document - A binary object that may be in 
various formats that is embedded in a Filing Review Message, is docketed in the 
Case History, and is stored as part of the Electronic Court Record.  
(Previously known as a Lead Document which I still prefer.)   

 

Attachment -A binary object that may be in 
various formats that is embedded in a Filing Review Message, is not docketed in 
the Case History but is stored as part of the Electronic Court 
Record.

 

All attachments must be associated with a 
"Document" embedded in the Filing Review Message.

 

1) Any Filing Review Message whether it is for case 
initiation or for existing case update must be able to include multiple 
"Documents".

2) Each "Document" within the Filing 
Review Message must be able to have court specific XML data associated with 
it.

3) Each "Attachment" must be able to have court 
specific XML data associated with it. (The challenge with this area is that some 
courts do not define all documents as docketed items, yet these documents carry 
case data that may be used to automate processes.)

4) Each "Attachment" may (must not sure of ) 
be assoicated to a "Document".

5) Each "Document" may have multiple "Attachments" associated to it.

6) When a "Document" is larger than a court specific size it must be broken 
down into multiple parts.  LegalXML Blue should define how the multiple 
parts are associated with the first portion of the "Document" and they can be 
included as "Documents" if the court dockets each portion in the case history or 
as "Attachments" if the court does not docket each portion.  This example 
points to an example of why "Attachment" specific data needs XML data associated 
with it to identify which part in the series it represents.

 

7) Regarding the Return Response Message, we must have a status at the 
Filing Review Message level and at each "Document" level.  I am not sure of 
the "Attachment" level yet, however I can see that it may be an issue in the 
future.

 

8) There is information that is general case information and there is 
information that is document specific.  Party information can be argued as 
either depending on the situation, and we must be able to carry that information 
in both the main body and document specific area.

 

9) We must have the ability to understand the condition of when a party is 
being added, and when a party is being updated.

 

10) Some Filing Review Messages may not contain "Documents" or 
"Attachments".

 

I support John Greacen's position that we must be able to carry any 
court specific data a court needs for automation on case initiation.  I 
also support the same position for existing case update.  What good is a 
standard that allows for some automation but not everything a court really 
wants.  This would simply put the courts in a position where they will wait 
for a standard that works for them and deviate from the limited 
standard.  That is one of the challenges we already face.

 

I struggle with the debate over whether to create a method of extending the 
XML data within the main SOAP Body or whether to keep the main body simple and 
straight forward.  I lean towards the complete separation which is cleaner 
to manage in interoperability but may not be as fast in processing because you 
have to extract the XML data out of a MIME embedded attachment.  This 
however leads to the next definition and requirement:

 

Embedded Processing Data - Some form of 
machine interpreted data, possibly an XML document instance, that is not 
associated with any specific "Document" or "Attachment" but is general data 
associated with the case, whether the data is for case initiation or for 
existing case update.

 

11) The main Body must be able to identify this type of data and possibly 
the format associated with this data.

 

I hope this answers the question that John Greacen 
posed as to whether any of the implementers had thoughts on these issues.  
In addition, it has been difficult to complete our assignment that Jim, Jim, and 
I had in New Orleans because we are not all currently part the the group seeking 
to define the XML message structures therefor the best I thought we could do is 
to lay out the requirements, however, I have included Jim Cabral's message he 
sent to Jim Harris and I seeking to further explore how we are going to address 
the related "Document", "Attachments" and associated XML data.

 

Dallas