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: "Scott Came" <>
To:
Date: Wed, 1 Jun 2005 15:35:36 -0700 (PDT)
I would be very much in favor of not continuing to overload "attachment".� If there is an alternative label
for the additional documents, it would be very helpful to switch to it.
> 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.
>
>
> While "exhibit" has other meaning - as in items
submitted in evidence in
> court - within the context of court filings, "exhibit" can be taken to
mean,
> fairly precisely, what we're using "attachment" for.
>
>
> This
doesn't solve the problem of the big document that is broken up into
> smaller files and then put back
together by having parts 2 and subsequent
> added as "attachments" to the "lead" (part 1).
Strictly speaking, not
> "exhibits," but this may work out.
>
>
>
> 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
> Department of Judicial Administration
>
> 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
>
>
>
>
>
> -----Original
Message-----
> From: [mailto:]
> Sent:
Wednesday, June 01, 2005 12:55 PM
> To:
> Subject: RE:
[legalxml-courtfiling] Case Initiation Elements
>
>
>
> 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
>
>
>
>
>
>
Follow-Ups:
Re: [legalxml-courtfiling] Case Initiation Elements
From: "Dallas Powell" <>
References:
RE: [legalxml-courtfiling] Case Initiation Elements
From: "Winters, Roger" <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
