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" <scott@justiceintegration.com>
- To: legalxml-courtfiling@lists.oasis-open.org
- 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
>
> roger.winters@metrokc.gov
>
>
>
> -----Original
Message-----
> From: Shane.Durham@lexisnexis.com [mailto:Shane.Durham@lexisnexis.com]
> Sent:
Wednesday, June 01, 2005 12:55 PM
> To: legalxml-courtfiling@lists.oasis-open.org
> 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:dpowell@tybera.com]
> Sent:
Tuesday, May 31, 2005 9:34 PM
> To: scott@justiceintegration.com; '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]