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:
To:
Date: Wed, 1 Jun 2005 12:54:33 -0700
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:]
Sent: Tuesday, May 31, 2005 9:34
PM
To: ; 'Electronic Court Filing
Technical Committeee'
Subject: Re: [legalxml-courtfiling] Case
Initiation Elements
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]
