I welcome any new names and definitions
that clarify what we are talking about. My first message was to
demonstrate some functions we need using old terms that I agree are overloaded
with meaning.
Dallas
----- Original Message -----
Sent: Wednesday, June 01, 2005 4:35
PM
Subject: RE: [legalxml-courtfiling] Case
Initiation Elements
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 >
> > > > >
--------------------------------------------------------------------- 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
|