-
Type:
Task
-
Status: Closed
-
Priority:
Major
-
Resolution: Fixed
-
Component/s: OS Submission
-
Labels:None
Submitted on Saturday, January 19, 2013 - 19:44
Submitted by user:
Submitted values are:
Submitter's Name: James Cabral
TC Name: LegalXML Electronic Court Filing
TC Email Address: legalxml-courtfiling@lists.oasis-open.org
Work Product Title: Electronic Court Filing v4.01
(a) COS URI:
http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4.01/ecf-v4.01-spec/cs01/ecf-v4.01-spec-cs01.html
(b) COS URI (editable source):
http://docs.oasis-open.org/legalxml-courtfiling/specs/ecf/v4.01/ecf-v4.01-spec/cs01/ecf-v4.01-spec-cs01.doc
(c) Certification by the TC that all schema and XML instances are well-formed
and that expressions are valid: We so certify
(d) A clear English-language summary of the specification:
This specification describes the technical architecture and the functional
features needed to accomplish a successful electronic court filing system,
and
defines both the normative (required) and non-normative (optional) business
processes it supports. The non-functional requirements associated with
electronic filing transactions, as well as the actions and services needed to
accomplish the transactions, such as network and security infrastruc-tures,
are
defined in related specifications, namely:
• Service interaction profile specifications that define communications
infrastructures, within which electronic filing transactions can take place
• Document signature profile specifications that define mechanisms for
stating
or ensuring that a person signed a particular document
This specification supports the following automated information exchanges:
• Transmission of documents in electronic form from law firms and from
other
persons and organizations to a court for entry ("official filing") into
the
court's official case records
• Recording of documents in electronic form from members of the court and
court administrators into the court's official case records
• Transmission of data needed to complete (or demonstrate the previous
completion of) financial transactions involving filing fees or the payment of
any other court fees, fines and financial obligations
• Transmission of the metadata needed to initiate a new case record in a
court's automated case management system (CMS) when the document being
transmitted is one that commences a new case in that court
• Transmission of the metadata needed to create an entry that records
(indexes) a filed document in a court's electronic listing of cases and
their
contents (variously called a "docket" or "register of actions")
• Transmission of the metadata needed to update the information recorded
about
a case that is maintained in a court's CMS
• Messages returned to the sender that confirm a court's receipt of the
sender's filing message
• Messages notifying the sender of events such as the entry of the
document(s)
submitted by the sender into the court record (or an error message stating
that
the document[s] could not be accepted for filing and stating the reason[s]
why)
• Queries to the court seeking information about data and documents held
within the court's official electronic records and the return of
information
in response to those queries
• Queries from filers for the court rules and requirements for electronic
filing
• Queries by filers seeking from the court record system the names and
addresses of parties in a case who must be served and whether by traditional
or
electronic means
• Transmission of copies of documents submitted for filing to the other
parties in a case who are registered to receive service electronically
In addition to filing of court case documents, this specification supports
"secondary service" - the delivery of copies of filed documents to
persons
who have already been made parties to a case. This specification does NOT
support "primary service," which entails the service of summonses,
subpoenas, warrants and other documents that establish court jurisdiction
over
persons, making them parties to a case. Therefore, this specification does
NOT
support the following automated information exchanges:
• A query by a filer seeking from the court record system the names and
addresses of parties in a new case who must be served to establish court
jurisdiction over them in the new case
• Transmission of copies of or links to documents submitted for filing to
any
party in a new case or any newly added parties in an existing case
This specification defines a set of core structures that are common to most
types of court filings and defines specific structures that apply to filing
documents in the following types of court cases:
• Appellate
• Bankruptcy
• Civil (including general civil, mental health, probate and small claims)
• Criminal (both felony and misdemeanor)
• Domestic relations (including divorce, separation, child custody and
child
support, domestic violence and parentage, i.e., maternity or paternity)
• Juvenile (both delinquency and dependency)
• Violations (including traffic, ordinances and parking)
Although ECF 4.01 does not define data structure elements specific to other
case
types (e.g., administrative tribunals), the basic structure will support
other
types of court filings and is extensible through court-specific and
case-type-specific extensions.
(e) Relationship of this specification to similar work:
National Information Exchange Model (NIEM)
NIEM conformance, as defined by the NIEM Implementation Guidelines (NIEM
Guide),
is a core objective of this specification. The NIEM is an XML standard
designed
specifically for justice information exchanges, providing law enforcement,
public safety agencies, prosecutors, public defenders and the judicial branch
with a tool to effectively share data and information in a timely manner.
The
NIEM provides a library of reusable components that can be combined to
automate
justice information exchanges. The NIEM removes the burden from agencies to
independently create exchange standards. Because of its extensibility, there
is
more flexibility to deal with unique agency requirements and changes.
Through
the use of a common vocabulary that is understood system to system, NIEM
enables
access from multiple sources and reuse in multiple applications. The use of
NIEM element names does not require any change in local legal terminology.
XML
tag names are invisible to the user of an application employing them.
The NIEM is most useful for describing common objects such as persons and
locations, and criminal justice-specific processes such as arrest, booking,
jail
and prosecution. The NIEM is not as well developed for describing
non-criminal
information exchanges and processes. ECF 4.0 uses the NIEM version 2.0 where
the structures and definitions correspond to the requirements of ECF 4.0.
The
development process, including the NIEM modeling process, is described in
Appendix B.
OASIS Universal Business Language
UBL is an OASIS Standard that provides a single ubiquitous language for
business
communication, and takes into account the requirements common to all
enterprises. UBL provides a shared library of reusable components, essential
to
interoperability that can be combined to create electronic business schemas.
Without a common set of base components, each document format would risk
redefining addresses, locations and other basic information in incompatible
ways.
ECF 4.0 employs the following structures in the UBL to describe filing
payments
and payment receipts:
Information about a charge or discount price component.
Information about a structured address.
Information directly relating to a specific payment.
W3C XML-Signature Syntax and Processing
The W3C XML Signature Syntax and Processing (XMLSIG) specification describes
a
mechanism for signing electronic documents. This mechanism allows recipients
of
electronic documents to identify the sender and be assured of the validity of
the electronically transmitted data. XMLSIG defines standard means for
specifying information content that is to be digitally signed.
ECF 4.0 employs the XMLSIG specification to describe digital signatures
applied
to the entire ECF 4.0 message transmission in order to provide
authentication,
encryption and message integrity. XMLSIG is also used in the ECF XML
Document
Signature Profile.
OASIS Reference Model for Service Oriented Architecture
The SOA-RM is a framework for understanding significant entities, and the
relationships between those entities, within a service-oriented architecture.
ECF 4.0 describes such an architecture and includes terminology that conforms
to
the SOA-RM.
OASIS Code List Representation (Genericode)
The OASIS Code List Representation format, Genericode, is a model and XML
schema
that can be used to encode a broad range of code list information. The XML
format is designed to support interchange or distribution of
machine-readable
code list information between systems. All ECF 4.0 code lists that are not
defined in the NIEM are provided in Genericode 1.0 format.
-(f) Statements of Use-
Link to Statement of Use #1:
https://lists.oasis-open.org/archives/legalxml-courtfiling/201301/msg00015.html
Link to Statement of Use #2:
https://lists.oasis-open.org/archives/legalxml-courtfiling/201209/msg00017.html
Link to Statement of Use #3:
https://lists.oasis-open.org/archives/legalxml-courtfiling/201208/msg00042.html
Additional Statements of Use:
-(g) Public Reviews-
30-day Public Review Announcement URI:
http://lists.oasis-open.org/archives/tc-announce/201102/msg00001.html
Additional Public Review Announcement URIs:
http://lists.oasis-open.org/archives/tc-announce/201110/msg00001.html
https://lists.oasis-open.org/archives/tc-announce/201204/msg00003.html
Comment Resolution Log URI:
(h) COS Ballot URI: https://www.oasis-open.org/committees/ballot.php?id=2344
Earlier attempts to standardize: No
(j) TC Comments Archive URI:
http://lists.oasis-open.org/archives/legalxml-courtfiling-comment
(k) Length of COS Public Review Requested: 61
Notes:
The results of this submission may be viewed at:
http://tools.oasis-open.org/issues/browse/TCADMIN