RE: [courtfiling-doc] Breaking Court Document out of Court Filing

From
Winters, Roger <>
Date
2003-05-19T15:49:45+00:00
ID
Thread
RE: [courtfiling-doc] Breaking Court Document out of Court Filing
Title: RE: [courtfiling-doc] Breaking Court Document out of Court Filing

Hello, ECFTC!

 

I want to share 1. A link to an article of
interest, 2. a comment on "display" of XML documents ("instances"),
and 3. comments on proposal(s) for a new technical committee (for "Court Document"
or for "Legal Document").

 

 
The May 15 issue of "Law.Com"
     included an article that relates to our work: http://www.law.com/jsp/article.jsp?id=1052440723645.

 

 
I acknowledge that a strong
     expression of the importance of a stable appearance for a legal document,
     particularly a court filing, has been made in several ways, including the
     Process Standards. There have, however, been discussions about alternate
     ways to reference information in documents (the real reason for
     pagination) in order to enable the fullest use of electronic document
     technology. One such alternative is the "paragraph numbering"
     idea where, based on some to-be-determined convention, the paragraphs (or
     paragraph units) in a document would be sequentially numbered so they
     could be referenced accurately even though different people might find
     them on different pages due to variances in their browsers, word
     processors, etc. One notion supporting this approach is that computers are
     very good at numbering things: it would seem that identifying numbers
     could easily be fixed to paragraphs within a given document. By
     definition, a change in the document that might affect its paragraph
     numbers would be a new version of the document. I hope such alternatives stay
     in view - holding on to "page" and "format" seems
     to me to be a form of holding on to paper! When considering paragraph
     numbering, please don't just imagine differences caused by using stylesheets
     that show up differently in one browser or another: Suppose a visually
     impaired person were to display a document in a very large font in order
     to read it -- the difference in apparent pagination would be extreme. (If
     this paragraph numbering practice were adopted, I predict a movement in style
     toward writing shorter paragraphs in legal documents would ensue.)

 

 
OASIS's allowing three
     members to initiate a technical committee opens the door to good and
     not-so-good results. To the good, it doesn't require that a large
     number be convinced in order to present a charter and propose work to be
     done. On the other hand, it makes it appear easier to form a new group
     than to confront difficulties, however severe or slight, in an existing
     technical committee where the work might well be most appropriately
     placed. I am aligned with those who believe that Court Document and Court Filing
     are so strongly related that it would be a mistake to develop them in
     separated efforts. I believe our TC as a whole needs to take ownership of Court
     Document and develop it alongside (or within) Court Filing - Blue. The
     TC has not had discussion along those lines yet because its current focus
     is in building the foundation for "Blue" through developing
     interoperability and process issues and models. 

 

While I might be
persuaded, after extensive discussion and exploration of alternatives, that a
parallel effort focused on "Legal Document" specifications might
make sense, my starting position is that the fundamental standards that should be
part of all of Legal XML's specifications need to be agreed upon first.
The technical architecture for transmittal, security, validation, etc., should,
I'd think, be essentially the same for all legal documents as they are for
court filings in particular. There should, I think, be a common vocabulary that
reflects a belief that "things legal" refer to the same people,
things, attributes, and relationships, whether they are in the context of a
court, a contract negotiation, a labor agreement, a statute, a marriage
license, or other. I have never been convinced that "translation tools"
will "take care of" the differences that come from having separate
and uncoordinated work products generated by a "Balkanized" approach
to standards development.

 

Best wishes,

 

Roger

 

Roger Winters

Electronic Court Records
Manager

King County

Department of
Judicial Administration

516 Third Avenue, E-609
MS: KCC-JA-0609

Seattle, Washington 98104

V: (206) 296-7838 F: (206) 296-0906



 

-----Original Message-----

From: John Greacen
[mailto:] 

Sent: Thursday, May 15, 2003 7:13
AM

To: 'Krause, Catherine';


Subject: RE: [courtfiling-doc]
Breaking Court Document out of Court Filing

 

The discussion in Atlanta focused on
several matters 

 

-        
One, should Court Document be incorporated into
Court Filing Blue?  Those who expressed views thought not.  The two
specifications should remain separate, although they would both evolve in the
same general directions for the Blue generation of TC specifications.

-        
Two, what changes need to be made to Court
Document as the subcommittee develops a schema-based specification?  Among
the issues discussed was a revisiting of a basic issue that the TC had grappled
with in the past - how can we guarantee to lawyers and to courts that XML
documents will retain their content and formatting when displayed on different
browsers and applications within law offices and courts?  Our previous
discussions all concluded that use of the same style sheet would obtain this
result.  All we needed to do was have the lawyer include the style sheet
with the XML instance, and "sign" both, and we could guarantee the
integrity of the content within the document and the format in which it
appeared.  The discussion in Atlanta reached the opposite factual
conclusion - at the current level of development of XML, we cannot be
assured of the integrity of the content or the format when documents are
displayed using different browsers and different applications.  TC members
in Atlanta stated, without contradiction, that if a document created with Court
Document 1.1 is displayed with a different browser than the one used to create
it, it may show different content and different formatting.  The
likelihood of those changes is not predictable.  It is also impossible to
require all participants to use the same browser and application to avoid this
result.  It was also pointed out that the same is true to a far lesser
extent for pdf - specifically -- that special characters can display
differently in a pdf than in the document from which it was created, such as a
special symbol used as a bullet displaying as a character instead.  Pdf,
however, has proved to be sufficiently representative to have earned the
confidence of lawyers and courts.  This discussion suggested to some of those
present that Court Document 1.1, and any future Court Document specifications,
will - at the current state of XML technology - be useful primarily
for form-based documents (in which only the data is of great consequence) and
not for "free text" documents.  We all agreed that we need to
do more testing of Court Document in different configurations to determine how
reliable it will be in practice.

-        
There was no intimation that the full Technical
Committee was uninterested in or unwilling to continue to work on these issues
with the Court Document subcommittee in the future.  In fact, this was one
of the very best and most thorough explorations of the issues associated with
Court Document that I have observed in the long history of the TC.  Dallas
Powell, Shane Durham and Dr. Leff made extremely valuable contributions to the
discussion of the issues that Rolly raised on behalf of the subcommittee.

 

The
discussion of a separate TC for court document took place on the conference
call following the Atlanta meeting, not at the Atlanta meeting.  It was
initiated by Diane Lewis, arising from her analysis of the charters of all of
the Legal XML Member Section Technical Committees for the Member Section
Steering Committee.

 

I
disagree with Jim Keane's suggestion that persons interested in a
separate Legal Documents Technical Committee should make a proposal to OASIS to
create one.  Given the importance of this issue to the Legal XML Member
Section, I believe that the matter should be studied by our new Steering
Committee and that all members of the Member Section should abide that the
Steering Committee's decision of the issue.  The discussion has
raised a number of valid points pro and con and we should rely on the
governance mechanism we have created to resolve them.

 

 

John M. Greacen

Greacen Associates, LLC

HCR 78, Box 23

Regina, New Mexico 87046

505-289-2164

505-780-1450 (cell)

 

-----Original Message-----

From: Krause, Catherine
[mailto:] 

Sent: Wednesday, May 14, 2003 9:46
AM

To:


Subject: RE: [courtfiling-doc]
Breaking Court Document out of Court Filing

 

John:

Your idea
sounds reasonable. 

I also
was not in Atlanta, and now re-reading the minutes (which I had skimmed previously),
I understand more about why this topic came up -- I apologize for not doing so
earlier.  The minutes seem to indicate that there was a discussion about
whether the Court Document standard should be merged into the Court Filing
standard, rather than have two separate standards, and that the topic was to be
discussed further at the next face-to-face in July.  The minutes do not
mention the discussion about Court Document separating from Court Filing and
going "on their own" as you describe below.

It might
be helpful for those of us who were not in Atlanta if someone who was in
Atlanta could clarify, or at least confirm that John's summary below was also
part of the conversation.

Thanks,

Catherine
Krause 

E-Filing Project Manager

King County Department of Judicial
Administration 

(206)296-7860 



  

 

-----Original
Message----- 

From: jmessing [mailto:] 

Sent: Wednesday, May 14, 2003 8:13
AM 

To: 

Subject: [courtfiling-doc] Breaking
Court Document out of Court Filing 

 

I
understand and appreciate the concern about retaining control within the CourtFiling
TC over the standards that relate strictly to court documents.

However,
there may be two levels here. 

First,
presenting a legal document in a format and manner that retains the "look
and feel" of paper. 

As I
understand the discussions at Atlanta, most participants felt that PDF did a
better job than XML at this stage of performing this first task and that
continued efforts towards a CourtDocument schema within the CourtFiling TC were
going to be deprecated in favor of using PDF. The consensus as explained to me
was that the participants in a CourtDocument standard could proceed as a
subcommittee on their own, but without support from the CourtFiling TC itself.
As I was not present, please correct me if I have mispoken.

But I
digress. 

At a second
level, there is a need to support the "hooks" for applications to
make use of the data in the XML documents. These are fairly rudimentary and
poorly understood at this stage in the evolution of CourtDocument, IMO.

We are
learning from the eContracts TC some of the latter techniques, as like
CourtDocument, eContracts require a familiar "look and feel" as well
as application "hooks." They are different than those for
CourtDocument, but related.

This
leads me to the conclusion that what is needed is a LegalDocument TC, where the
similarities and differences between the various "flavors" of
documents can be normalized, using techniques of a "core" schema,
inheritance of the "core" elements and attributes, extensions to the
various domains: CourtDocument, eContracts, etc. as well as the types of hooks
that are needed for specific applications in the various domains. I would add
to this a universal citation standard, which the ABA has requested and
authorized, and which does not strictly speaking fall within CourtFiling.

I would
therefore like to see CourtDocument itself remain where it is, within the
CourtFiling TC, and a new LegalDocument TC created, where the development of
these techniques across the board (our original "horizontal" concept
from the early days of LegalXML) can be developed. Then with a liasion from
CourtFiling, the learning of this new TC, as appropriate, can be ported to
CourtDocument, under the control of CourtFiling.

I would
be interested in hearing from others about this idea. 

=====================================================

All: 

If a
proposal is made to revise the Court Filing TC charter to separate Court
Document out and make it a separate TC, I suggest that rather than Court Filing
TC members justifying the current charter where Court Document is part of it,
the opposite needs to occur -- those proposing to separate Court Document from
Court Filing need to make the case for doing so.

I do
agree with Diane's statement that "close identification" between the
groups has not been observed.  However, I view this as an issue to be
addressed within the TC, not a reason to separate Court Document from Court
Filing.  From my point of view as to what is needed for our electronic
filing project (which I believe will also be needed for others), we need both a
Court Filing standard and a Court Document standard, or possibly one standard
that covers both.  The Court Document standard needs to include all the
data tags that we need in order to process e-filed documents; in other words,
it needs to include tags for all of the data that our staff currently keys into
various CMS/DMS systems -- this is at a more detailed level than those included
in the ECF 1.1 standard, which might be enough to get a document into the case
file, but does not include tags for all of the additional data that we enter in
various systems for various document types.  Until that level of detailed
data tags are included, we will not be able to reach the ultimate goal of fully
automating the processing of electronically filed documents, at least not in a
large court of general jurisdiction like ours where we have multiple systems
where data is entered today, and new ones being developed all the time. 
It will take time to identify all of the needed tags, but I think we can get there. 
The current Court Document standard is a good starting point that can be built
upon for specific document types.

My view
of the purpose of the Court Document standard is that it is to tag the data
used by the clerk and/or court, the data that is of use to practitioners for
their own purposes, as well as for other purposes such as electronic service,
etc.  I do not feel that those members of the TC interested in Court
Document should need to participate in a separate TC to ensure that the Court
Document standard meets our needs; the additional time to attend meetings of
multiple TCs is something that would be very difficult for many of us to
do.  At this point, I strongly oppose separating Court Document out of the
Court Filing TC.  My primary concern is that there would be even less
identification with the Court Filing TC as a whole than there has been in the
past.  Unless someone makes a strong case for doing so, I would be voting
that I cannot live with a proposal to separate Court Document from Court
Filing.

Thanks, 

Catherine
Krause 

E-Filing Project Manager 

King County Department of Judicial
Administration 

(206)296-7860 

 

  

 

-----Original
Message----- 

From:  [mailto:] 

Sent: Monday, May 05, 2003 8:53 AM 

To:
''; '' 

Subject: RE: [courtfiling-doc]
Breaking Court Document out of Court Filing 

 

thanks Roger
for quick response, 

i would
suggest that the Court Filing stakeholders who have an interest in XML court
document standard consider joining a separate Court Document TC .... 

i have
not seen demonstrated at the Court Filing meetings the "close identification"
between the two at the meetings i have attended.....  the last set of
meeting notes to my mind indicate the opposite... that the court filing
envelope /transmission capability takes any BLOB... not exclusively a document
that authored/created based on XML technologies/standards.

i would
welcome a list of reasons from you and/or other ECF stakeholders as to why the
document/filing components should remain in tandum.... 

diane 

 

-----Original
Message----- 

From:  [mailto:] 

Sent: Monday, May 05, 2003 11:40 AM

To:
 

Subject: RE: [courtfiling-doc]
Breaking Court Document out of Court Filing 

Importance: Low 

 

Diane, 

I will,
of course, represent the ECF TC to the Steering Committee by conveying its
requests, recommendations, etc., there. There are, by the way, specific OASIS
procedures relating to the formation of Technical Committees, etc. Whatever
decisions are reached would be implemented within those procedures. 

Now,
writing as an individual member of the ECF TC, I think this is the first time
I've heard a proposal to move the Court Document committee toward being its own
TC. I would think that Court Document needs to become more closely identified
with Court Filing, where many of its stakeholders are involved.

Roger
Winters 

Electronic Court Records Manager 

King County 

Department of Judicial
Administration 

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: Monday, May 05, 2003 8:08 AM 

To:
 

Subject: [courtfiling-doc] Breaking
Court Document out of Court Filing 

Roger, 

 i am addressing this message
through the court document filing SC...instead of directly to you.... so others
can provide their thoughts.

I would
like to request that you along with elected members to the LegalXML member
Section board... consider a realignment of Court Document ... instead of being
designated as a subcommittee under Court Filing.  I propose that

the
community consider it a separate TC....   the charter for the 

subcommittee can be rewritten to
justify the need to place a definite boundary between court filing and court
document. 

i look
forward to learning your detailed views on this proposal as well as learning the
views of other court document SC members.

thanks
for considering this idea.... diane