[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [legalxml-courtfiling] Case Initiation Elements
|
Regarding "attachment," often it is referred to as an "exhibit" with regard to a court filing. That is, there is the "lead document" and then there are perhaps "exhibits" that are "stapled" to it.
I'm not saying this is THE answer, but when someone identifies a term that is troublesome from having multiple meanings in different contexts, we need to seek out alternatives, so we can proceed with as much clarity as possible.
Roger Winters King County 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 roger.winters@metrokc.gov
-----Original Message-----
Various comments on various subjects:
>>Dallas>> 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.
I took a look at John's document. By and large, I think the values he has identified should be explicitly expressible in our XML messages.
I think we need many more discussions about *where* in the XML some of these values belong.
More importantly, at what point in our standards-development process do we want to tackle criminal and traffic stuff? (We have no storyboard to accompany these scenarios, do we?)
I had thought that we were initially tackling civil/probate scenarios and then tackling other types of cases in later releases of the standard.
>>Dallas>> 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.
I think this definition needs more work.
First of all, I will lose my mind if we continue to call "the functional-thing-which-is-not-a-leadDocument" an 'Attachment'. The term 'attachment' has lots of technical meaning which gets in the way of our functional discussions.
I suggest (and will now use) the term 'supportingDocument' as 'the functional-thing-which-is-not-a-leadDocument'.
The question is then 'how does supportingDocument differ from a leadDocument'?
The proposed definition's qualifier that a 'supportingDocument' is not to be recorded in the registerOfActions is not necessarily true. The court might-or-might-not record *ANY* document. The possible persistence of the document as part of the court record should not effect it's functional purpose in a filing. A filer does not identify a document as 'lead' or 'supporting' based on how they think the document will be persisted in the court record.
Here are some things I think do functionally distinguish supportingDocuments: - a supportDocument does not, by itself, describe a desired action of the court. - a supportingDocument is not directly related to a filing; it is a child of (in support of) some other document.
>>Dallas>> When a "Document" is larger than a court specific size it must be broken down into multiple parts.
I think the scenario more likely comes up because of the underlying DMS of the court. Many DMS's use multiple, single-page tiff files to represent a logical document.
At LexisNexis, our internal XML structure attempted to address this possibility in this way:
Our functional document consists of: - functional document properties (id, type, title, page-count, etc.) - documentContentList, consisting of one or more documentContent structures
Our documentContent structure expresses the technical information (mimeType, bytesize, etc) about the file(s)/uri(s)/mime-encoding that, collectively, represent a logical document. It also expresses the correct functional order of each documentContent structure.
In general, this approach allows one logical document, to be expressed by multiple physical files.
I believe this approach is similar to what Dallas proposes to be included in our standard. And, I believe the scenario I described is further justification for it.
However, I must confess, though the internal LexisNexis XML standard has this feature, we have yet to ever need it. Every court we integrate with, so far, has strongly preferred a single-file approach - even if they have to turn around and break up the single file into multiple tiffs for their DMS. As for query scenarios: we have not yet had to retrieve multiple, single-page tiff files from the court, even though, it was the query-scenario where we most anticipated this documentContentList approach would be needed.
>>Dallas>> 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.
As a member of this standards body, with my standards-cap on my head and a deadline looming, I say let our standard for extensions be an entirely separate datafile, to be included as a 'message attachment' to whatever message that is being extended. (i.e. let's go with Cabral's suggestion - it will certainly work).
Now, placing my implementer-cap on my head, and imagining how I would extend a message when I need to send a couple of extra data tidbits to the court, I can tell you that I will almost certainly choose to bend/overload/stretch an existing GJXDM element to carry the extra tidbits. For one or two extra pieces of data, I will avoid creating a special tag-along data file. Tag-along files are far too inconvenient for a simple handful of special values.
And, I suspect other implementers will feel the same about it.
In the end, we'll still end up with a standard that promotes the use of GJXDM elements for purposes other than for what they were intended, which is exactly what we were trying to prevent (ironic?).
And, so, like Dallas, I struggle too.
Vader: "Luke, I have extended your standard." Luke: "Nooooooooooooooooooooo!!!!!!!!!!!!!" - Shane Durham LexisNexis
From: Dallas
Powell [mailto:dpowell@tybera.com] 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]