Legalxml Court Filing Specification

LegalXML Court Filing Specification

Working Draft 04, September 9, 2005

Document identifier:

wd-LegalXML-Specifications-01.doc

Location:

Editor:

[List your editors here; check whether “Editor” header should be plural]

Contributors:

Shane Durham, LexisNexis

Eric Tingom, eCorridor, Inc.

Tom Clarke, WashingtonState Administrator for the Courts

Scott Came, JusticeIntegration Solutions, Inc.

Dallas Powell, Tybera Development Group, Inc

James Cabral, MTG Management Consultants, LLC.

Rex McElrath, Judicial Council of Georgia

Donald Bergeron, LexisNexis

James Cusick, Wolters Kluwer

John M. Greacen, Greacen Associates, LLC

Roger Winters, KingCounty, Department of Judicial Administration

Abstract:

This document defines the LegalXML COURT FILING Specification, consisting of a set of non-proprietary Web services and ebXML specifications, along with clarifications and amendments to those specifications, which promote interoperability.

Status:

This document is a Working Group Draft and has NOT been accepted by the Working Group as reflecting but is to serve as the basis for discussions. It is a work in progress, and should not be considered authoritative or final; other documents will superseded this document.

Committee members should send comments on this specification to the list. Others should subscribe to and send comments to the mailto: list. To subscribe, send an email message to mailto:?subject=Subscribe with the word "subscribe" as the body of the message.

Table of Contents

1Introduction

1.1Notational Conventions

1.1.1Visual Indicators

2Design Principles and Concepts

2.1Design Philosophy

2.2Key Design Terms and Concepts

2.2.1Requirements for Major Design Elements:

2.2.2Requirements for Designing All Messages:

2.2.3Court Policy

2.2.4Hash and Signatures

2.2.5Archival Storage

2.2.6Date and Time Format

3Major Design Elements

3.1Filing Assembly MDE

3.1.1Filing Assembly Glossary

3.1.2Filing Assembly Overview

3.1.3Filer Review Filing Callback Service

3.2Filing Review MDE

3.2.1Filing Review Glossary

3.2.2Filing Review Overview

3.2.3Review Filing Service

3.2.4Record Docketing Callback Service

3.3Court Record MDE

3.3.1Court Record Glossary

3.3.2Court Record Overview

3.3.3Record Docketing into the Court Record Service

3.4Service MDE

3.4.1Service Glossary

3.4.2Service Overview

3.4.3Serve Filing Service

3.5Service Registry MDE

3.5.1Service Registry Glossary

3.5.2Service Registry Overview

3.5.3Get Service Registry Information

3.6Query MDE

3.6.1Query Glossary

3.6.2Query Overview

3.6.3Calculate Fees

3.6.4Case List Service

3.6.5Case Service

3.6.6Document Service

3.6.7Filing List Service

3.6.8Filing Service

3.6.9Filing Status Service

3.7Court Policy MDE

3.7.1Court Policy Glossary

3.7.2Court Policy Overview

3.7.3Court Policy Service

4Message Types

4.1ReviewFilingMessageType

4.2ReviewFilingCallbackMessageType

4.3RecordDocketingMessageType

4.4RecordDocketingCallbackMessageType

4.5CourtPolicyMessageType

4.6ServiceInformationQueryMessageType

4.7CalculatedFeesQueryMessageType

4.8CaseQueryMessageType

4.9CaseListQueryMessageType

4.10DocumentQueryMessageType

4.11FilingQueryMessageType

4.12FilingListQueryMessageType

4.13FilingStatusQueryMessageType

4.14FilingPayment

4.15CaseTypeSpecificInformationType

4.15.1Bankruptcy

4.15.2Civil

4.15.3Criminal

4.15.4Domestic relations

4.15.5Juvenile

4.15.6Traffic

4.16Implementation Notes

4.16.1WebService Profile

5References

5.1Normative

Appendix A. Acknowledgments

Appendix B. Revision History

Appendix C. Notices

1Introduction

This document is a Proposed Standard developed by the OASIS LegalXML Member Section Electronic Court Filing Technical Committee.

This document is intended to describe the information required for Electronic Court Filing 3.0 and the structure of that information. No information regarding the content of any pleading or other legal devices (e.g., contracts, orders, and judgments) is included, other than what is required to accomplish the intended task.

This specification is the product of a consensus process. Many items covered by the standard attracted valuable inputs from multiple viewpoints. The views about items were often not identical. When resolution of items needed to be reached, discussion on proposed resolutions were closed only when the question “Is there anyone cannot live with this?” was answered in the negative.

The Electronic Court Filing (ECF 3.0) provides an open, non-proprietary digital message format for all types of court filings, queries and related responses. ECF 3.0 addresses telecommunications method as part of messaging profiles. The ECF 3.0 Message format is compatible with emerging technologies such as Web services.

Key benefits of ECF 3.0 will include interoperability between courts, vendors, and the legal community and operational complexity by eliminating the need for multiple custom software interfaces to the many systems involved in filing court documents.

Electronic Court Filing 3.0 will support the submission of documents in the following case types:

bankruptcy

civil (including general civil, mental health, probate and small claims)

criminal (including felony and misdemeanor)

domestic relations (including divorce, separation, child custody and child support, domestic violence, maternity and paternity)

juvenile (including delinquency and dependency)

traffic

Although ECF 3.0 does not contain a separate set of data elements for that purpose, the basic structure will also support filings in appellate courts. Future versions of ECF 3.0 will enhance the metadata for appellate filings, address filings in administrative tribunals, address primary service (the delivery of documents such as summonses, subpoenas, and warrants that establish a court’s jurisdiction over a party), and consider how the standards for filing of documents intended for filing with a court relate to standards for filing other documents in the offices of elected clerks of courts.[1]

1.1Notational Conventions

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119.

wd-LegalXML-Specifications-04.doc9-Sep-2005

1.1.1Visual Indicators

In the following sections, different fonts are used to identify the meaning of the term. Except within the Document. Type Definition (XML Schema), the font size is 8 point.

The Arial font identifies the names of elements and attributes.

A Bold font, whether in Arial or Times New Roman, is used for emphasis or to identify the beginning of a

definition.

Courier New identifies XML Schema text. It is also used, when enclosed in quotation marks, to indicate user-supplied attribute values or other strings, including attribute values. The font size for the entirety of the XML Schema is reduced to 8 point.

2Design Principles and Concepts

2.1Design Philosophy

Among the principles which guided the design of the Electronic Court Filing 3.0 Message were:

InteroperabilityFirst and foremost, the Electronic Court Filing 3.0 Message should provide a means for interoperable exchange of court filings among all types of court information systems.
CompletenessThe Electronic Court Filing 3.0 Message format should provide for all the elements of an effective public warning message.
Simple implementationThe design should not place undue burdens of complexity on technical implementers.
Simple XML and portable structureThe primary anticipated use of the Electronic Court Filing 3.0 Message is as an XML document.
Multi-use formatOne message schema supports multiple message types in various applications.
Familiarity The data elements and code values should be meaningful to the legal community and non-expert recipients alike.
Interdisciplinary and international utilityThe design should allow a broad range of applications in Court management and associated applications and should be applicable worldwide.

2.2Key Design Terms and Concepts

2.2.1Requirements for Major Design Elements:

Note: The following requirements were used as a basis for design and review of the Electronic Court Filing 3.0 specification. This list is non-normative and not intended to be exhaustive.

Each implemented MDE MUST maintain both an input and output functions of each separate MDE in order to be in compliance.
Names in UML Domain Models will be normative, will govern and will be used.
A recipient MDE must be able to tell what profile is used by the sender MDE of a message and that the sending MDE location ID is self assigned by the MDE and unique.
It will be assumed that a state AOC will host all implemented profiles for all courts within a state.

Major Design Element (MDE):

A logical grouping of operations representing a significant business process supported by ECF 3.0. Each MDE operation receives one or more messages, returns a synchronous response message, and optionally sends an asynchronous response message back to the original sender.

Electronic Court Filing 3.0 defines five Major Design Elements (MDEs). They are:

Filing Assembly MDEenables a filer to create a filing message for submission to a court and returns filing callback messages to the filer
Filing Review MDEenables a court to receive and review a filing message and prepare the contents for recording in its case management and document management systems and sends callback messages concerning the filing to the Filing Assembly MDE
Court Record MDEenables a court to record electronic documents and docket entries describing them in its case management and document management systems and returns a callback message to the Filing Review MDE
Service MDEenables a filer or a court to transmit filings to other parties who are participating in the case electronically who are entitled to copies of the filing
Service Registry MDEenables a filer or court to obtain the electronic and/or mail addresses of all parties in a case that must be served.
Query MDEenables a court to provide inquiry and response to other parties about case and related filing information.
Court Policy MDEenables a court to provide both design time specifications and run time information (information that will be updated from time to time [such as lists of acceptable document types, criminal charges, and civil causes of action]).

Message Transmission: The sending of one or more messages and associated attachments to an MDE. Each transmission must conform to the signature of a single operation on the receiving MDE, as defined in the ECF 3.0 specification.

Operation (or MDE Operation): A function provided by an MDE upon receipt of one or more messages. The function provided by the operation represents a significant step in the court filing business process. A sender invokes an operation on an MDE by transmitting a set of messages to that MDE, addressed to that operation.

Operation signature: A definition of the input message(s) and synchronous response message associated with an operation. Each input message is given a name and a type by the operation. The type is defined by a single one of the message structures defined in the ECF 3.0 specification.

2.2.2Requirements for DesigningAll Messages:

Note: The following requirements were used as a basis for design and review of the Electronic Court Filing 3.0 specification. This list is non-normative and not intended to be exhaustive.

A filing into an existing case will need to use the same structure for a filing initiating a new case, so that all of the metadata that may need to be changed – added, deleted, or updated – can be included along with the new document.
All metadata for an attachment includes the IANA defined mimetype, the file size, the software description, and the software version. That data has been describedas base 64 encoded “insertions” rather than attachments.

The same basic structure will be used for all messages.

Message Stream:

The message stream is the series of bytes of data that are transmitted between major design elements (MDEs). The stream has a structure (that is, the series of bytes is organized into logical pieces or segments).

Core Message:

The core message is a series of bytes in the message stream that represent an XML document (that is, a well-formed XML data structure with a single root element); the XML document contains the following information:

Information about the message itself, such as identifiers for the sender and receiver, sending and receiving MDEs, and submission date and time; this information is called the message information

Information about each of the logical documents associated with the message; “logical” documents consist of lead documents and supporting documents, as described below

Document:

A document is information about a logical document associated with the message. A logical document in this sense is the electronic representation of a single, whole, physical paper document. The document information contains two sub-structures:

Document metadata, such as the title, type, identifier, etc.

Either a “pointer” or link to the binary representations of the physical document (“representations” is plural, since a logical document may be split into several physical parts to satisfy court requirements as to maximum document size), or the encoded binary representation of the physical document embedded within the XML structure

There are two kinds of logical document: lead documents, and supporting documents.

A lead document is defined as one that will be placed on the court’s register of actions (docket). A supporting document is one that supplements the lead document; often the lead document will contain language that makes reference to a supporting document. Each supporting document is associated with one and only one “parent” lead document. This association is accomplished via the parentLeadDocumentID property on the Document class (see Review Filing domain model.)

Each filing has to have a leadDocument. A leadDocument does not have to have a supportingDocument.

Supporting documents must have a logical sequencing with respect to their parent lead document – e.g., Attachment 1, Attachment 2, Exhibit 1, Exhibit 2, etc. This sequencing is indicated by the value of the supportingDocumentSequenceIdentifier property of the Document class.

Attachment:

Information transmitted between MDEs that is of an arbitrary format, and is related to the message(s) in the transmission in a manner defined in the ECF 3.0 specification. An attachment may be in XML format, non-XML text format, encoded binary format, or un-encoded binary format.

An attachment is a series of bytes in the message stream that represents the contents of all or part of a physical document. The contents are preceded by one or more “headers” that uniquely identify the attachment (via an identifier) and the format or type of the attachment. Note that the contents of an attachment can be binary octets (the “raw” binary data of the physical document), binary data encoded in text (e.g., via base-64 or some other algorithm), XML text, or plain text.

Attachments appear in the message stream after the core message. The order of attachments is unimportant and cannot be treated as significant. In particular, attachments representing the content of lead documents need not appear before attachments representing the content of supporting documents.

Within the core message, each Document structure contains one or more Attachment structures. In this way, the logical Document is associated with one or more attachments that represent the physical content of that document. Each attachment structure contains two properties. One property (AttachmentID) uniquely identifies the attachment; the value of this property must be the identifier that appears in the identification header preceding the attachment content in the message stream. The other property (AttachmentSequenceID) indicates the order in which this attachment is to be assembled within the context of its parent logical document. If a logical document is associated with only one attachment, then the AttachmentSequenceID will have the value 1.

Handling “embedded” attachment data:

When “embedding” the contents of attachments (as defined above) within the core message structure. The Implementer MUST do so using the documentBinaryData property on the Document class.

Note: Messages that Don’t Involve Attachments

Queries Request portion of the message will NOT have attachments; however, the basic message stream structure will still work for them.

Document Metadata

Document metadata includes the following:

Document identifier – unique number identifying a whole document – including all its parts – within the context of a filing

Supporting document sequence number – indicates the order in which the filer wishes to relate this to the lead document among multiple supporting Documents associated with the same leadDocument.

A filer has the option to include all of the supporting documents together with the lead document as a single document. The filer is not required to separate out the supporting documents as independent, separately identified documents. But the filer (or the Filing Assembly MDE) has this option, which in most instances will be more convenient to the filer.

documentType – is defined as the docket code used by the court’s CMS to generate the documentType text in the docket or register of actions. This clarifies that all that is transmitted is the docket code and not the text of the documentType.

The element documentDescriptiveText is used to transmit additional information to be added to the documentType text to create the docket entry.

PriorRelatedDocumentId is a reference to a previously filed document to which this document is related. For instance, Response to Motion to Dismiss is related to Plaintiff’s Motion to Strike Defendant General Motor’s Motion to Dismiss for Lack of Subject Matter Jurisdiction.

filingPartyID and filingAttorneyID(s) are court generated IDs for parties and attorneys unique to a case. A court can decide to use permanent IDs – a single ID that is assigned to a party or attorney across all cases in the court. Many courts use attorney bar number as such a permanent ID for attorneys; and there are some courts that attempt to maintain a single party record in their databases even though a party appears in many cases (so, for instance, a change in address entered once will flow through to every case in which that party appears). These IDs cannot be submitted with an initial filing unless the court generates such permanent IDs, and has generated and assigned them for all parties and attorneys in the case. One of these IDs may be the same as submitter ID; however, the submitter ID can be different from both.

The purpose of all five of these metadata items are for construction of the docket entry for a document – Response (documentType) With Additional Materials (documentDescriptiveText) filed by Attorney Able M. (filingAttorneyID) on behalf of Any Corporation, Inc. (filingPartyID) to Motion for Summary Judgment filed on behalf of Baker C. (PriorRelatedDocumentId).

Note:Metadata element or elements for document size were not created. This information should be contained as part of the description of an attachment and conveyed by the messaging profile as a nonfunctional requirement.

Containment structures involved in the message stream diagrams:

wd-LegalXML-Specifications-04.doc9-Sep-2005

The following diagram illustrates the scenario of a message stream involving two lead documents, the first of which has two supporting documents. The second lead document has no supporting documents. All four logical documents are associated with a single attachment.