|
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
----- Original Message -----
Sent: Tuesday, May 31, 2005 1:03 PM
Subject: RE: [legalxml-courtfiling] Case
Initiation Elements
Just for the record, I'm completely neutral on whether the more
extensive set of elements is included in the Review Filing message
structure. I think this should be determined by those with experience
implementing our envisioned Filing Review MDE functionality, and business
expertise, as John suggests.
However, I can say that modeling and
mapping the more extensive set of elements presents a schedule risk for
us. Assuming we decide to move forward including the elements, we'll
need to figure out how to mitigate the schedule impact for early July.
Whatever strategy we use, we should seek to reuse the work already done on
reference IEPs in these areas...that will reduce (but not eliminate) the
schedule impact.
> Tom and Scott - This is all news to me. I have
been under the impression,
> from the earliest days of the TC, that our
XML specifications have to
> include the information needed by courts to
initiate new cases, in all case
> types. That is information that needs
to come in XML so that it is
> available directly to the court (or the
Filing Review MDE) for creation of
> the case opening information for
filing of complaints, petitions,
> informations, and indictments that
create new cases. If the data is not
> there, the court cannot file
these documents. Going down into another layer
> of the message
structure to find this information - where according to Scott
> it would
not necessarily be in XML at all - seems to me to create problems
> for
implementers.
>
> I read the Court Filing Blue requirements
document to be consistent with my
> prior understanding that this
information is included within the Blue
> specification and schema. I
guess this shows that there are problems with
> the requirements
documents if we three can read it and come to such
> different
expectations about this important part of the efiling process.
> When we
discussed the issue in New Orleans - when I took on responsibility
> for
collecting this information - no one suggested that it was out of
scope
> for Blue. When I collected the data from multiple sources,
several of whom
> are TC members (including Dallas, Robin, Roger, and
Jim Harris), no one
> suggested that it was outside the scope of
Blue.
>
> I am open to discussion of this issue, and am willing
to consider
> alternative approaches. But the matter requires discussion
on the list.
>
> Dallas, Shane, Don, Jim Beard, Shogan Naidoo,
Robert DePhillips and other
> implementers - do we need to include this
information in Court Filing Blue
> or can we create a structure that
posits its appearance in some part of the
> Court Filing Blue message
that is not defined in Blue?
>
> I will make sure that this issue
is on the Atlanta face to face agenda. But
> I would appreciate some
discussion on the list prior to the meeting.
>
> _____
>
> From: Clarke, Thomas [mailto:tclarke@ncsc.dni.us]
> Sent:
Tuesday, May 31, 2005 6:19 AM
> To: scott@justiceintegration.com;
Electronic Court Filing Technical
> Committeee
> Subject: RE:
[legalxml-courtfiling] Case Initiation Elements
>
> I was under
the same impression as Scott. Typically, the minimum case
> initiation
and document indexing elements are restricted to somewhere around
> 10
to 15 data elements. The rest go into the appropriate IEP. At least
>
that is the strategy assumed by Global and the GJXDM folks.
>
>
-----Original Message-----
> From: Scott Came
[mailto:scott@justiceintegration.com]
> Sent: Monday, May 30, 2005 4:43
PM
> To: Electronic Court Filing Technical Committeee
> Subject:
Re: [legalxml-courtfiling] Case Initiation Elements
>
> Thanks
John.
>
> This is certainly a substantial list of data elements.
I've also noticed
> that there is some overlap with the criminal
complaint reference IEP work
> previously undertaken by the law
enforcement reference IEP projects earlier
> this year (based on work
done earlier in LA County), and also the NCSC
> traffic citation
reference IEP.
>
> I had thought our approach was to include such
instances of other reference
> IEPs as one of the documents in the Blue
message structure, with only
> "basic" case information in the main body
of the Blue message. For
> instance, it would certainly be
straightforward for law enforcement to file
> a traffic citation case by
including in the main Blue message body the basic
> information (parties
names, court info, case title, case type, etc.) Then
> the document
(what we used to call the lead document) would contain the full
>
citation information. If this were XML, we would hope it would be
something
> close to (or derived from) the citation reference IEP, but
ultimately it
> would be whatever is standard in that jurisdiction. But
it would not have
> to be XML. Regardless, the "basic" case information
included in the Blue
> message body would be standard for all compliant
implementations...this is
> what we must define in the
specification.
>
> Has this approach changed?
>
> In
any case, knowing how long it took to produce the current drafts of
the
> criminal complaint and citation reference IEPs, doing something
similar
> would take much more time than we have allotted for this
week's exercise.
> If this list of elements is to be included, we'll
need to plan on a second
> session at a later time.
>
>>
I attach a Word table setting forth the case initiation data elements
that
> I
>> have discovered to date. They include input from
the Administrative Office
>> of US Courts, Orange County, FLA,
Minneapolis, Missouri, Utah, and King
>> County, WA. The list
includes case initiation data for criminal, civil,
>> bankruptcy,
family, juvenile delinquency, juvenile dependency, mental
>> health,
traffic and probate cases.
>>
>> I am indebted to all who
sent data elements to me.
>>
>> The exercise of putting this
together convinces me that we need to include
>> some mechanism for
easily extending our schema(s) to allow for the
> exchange
>>
of additional data elements. After I had incorporated several criminal
>
data
>> element sets, I assumed that I had the matrix well populated.
However, I
>> found that each additional set of elements from a new
jurisdiction
>> contributed several new elements not used in the
multiple element sets
> that
>> I had already
incorporated.
>>
>> In short, I consider this a very
substantial list of case initiation
>> elements that will impress our
stakeholders of the breadth of our inquiry.
>> But I know it is not
exhaustive, and, as Dallas Powell continually points
>> out, it
cannot be made exhaustive no matter how much work we commit to the
>>
task because of the unique data elements used and therefore required
in
>> different states and different courts within some
states.
>>
>> I hope this is helpful to the reference
document effort at the end of this
>> week. I leave it to Scott Came
to determine if and how it can be used in
>> that
exercise.
>>
>> John M. Greacen
>> Greacen
Associates, LLC
>> HCR 78 Box 23
>> Regina, New Mexico
87046
>> 505-289-2164
>> 505-289-2163 (fax)
>>
505-780-1450 (cell)
>> john@greacen.net
>>
>>
---------------------------------------------------------------------
>>
To unsubscribe from this mail list, you must leave the OASIS TC
that
>> generates this mail. You may a link to this group and all
your TCs in
> OASIS
>> at:
>>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
---------------------------------------------------------------------
To
> unsubscribe from this mail list, you must leave the OASIS TC that
generates
> this mail. You may a link to this group and all your TCs in
OASIS at:
>
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
--------------------------------------------------------------------- To
unsubscribe from this mail list, you must leave the OASIS TC that generates
this mail. You may a link to this group and all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|