Status of Document

This is a Court Filing Work Group Draft Standard for review and discussion by
interested members.

1. Introduction

This document is intended to describe the information required for marking up
the contents and structure of electronic court documents using XML.

This document is a Proposed Standard collaboratively developed by the
COSCA/NACM Joint Technology Committee and the Legal XML Court Filing Workgroup.

This proposed standard Court Document 1.1 DTD is the product of a consensus
process. Many items are the result of input from multiple viewpoints. It also
borrows extensively from the
Legal XML Court Filing 1.1 standard
(2002-02-18). This proposed
standard is a work in progress and further development of the standard is
anticipated and welcome.

1.1 Conventions

Within this document the terms "shall" or "must" describe mandatory items. The
term "may" describes optional items.

This proposed standard adheres to the conventions followed in the Legal XML
Court Filing 1.1 standard with respect to element and attribute naming and the
capitalization of XML tags.

1.2 Description

This document describes an XML DTD for validating the syntax of XML court
documents. This document itself does not set out the proposed Court Document
1.1 DTD in a format suitable for use. For instance, this document includes
explanations of various elements and attributes used in the proposed DTD that
are not formatted as comments. It also uses whitespace and color to make the
entity, element, and attribute declarations used in the DTD easier to read.
However,
Section 2.1
contains a link to the proposed
Court Document 1.1 DTD in usable format.

This document also contains a simplified version of the full Court Document 1.1
DTD. The simplified Court Document 1.1 DTD seeks to provide a
smaller and somewhat easier to use subset of the full Court Document 1.1 DTD.
Documents written using the simplified Court Document 1.1 DTD will be
completely valid against the full Court Document 1.1 DTD (although the reverse
will not necessarily be true). It is assumed that the simplified Court Document
1.1 DTD will be suitable for use in many instances where the more richly
structured mark up of the full Court Document 1.1 DTD is not needed.

All appendices are non-normative and may contain well formed, valid example XML
court documents for purposes of illustration only. If an inconsistency arises
between an example and the Court Document 1.1 DTD, the DTD shall control.

1.3 Assumptions and Requirements

1.3.1 Assumptions about Authoring and Displaying XML Documents

Creating XML documents is different from authoring documents in a word
processor. The author of an XML document must not only create the text of the
document but also must select and include the appropriate XML markup that
describes that text. XML authoring applications can simplify the process by
providing menus, forms, buttons, or similar ways for an author to identify and
designate the appropriate tags to describe the text content of an XML document,
but it nevertheless takes more physical and mental effort (and extra
time) to create an XML document than to create a text document in a word
processor. Thus, facilitating ease of use in creating XML court documents has
been a primary consideration with respect to the Court Document 1.1 DTD.

The Court Document 1.1 DTD favors relative simplicity, consistency, and
flexibility in its XML content models over comprehensive detail and rigid
structure. The Court Document 1.1 DTD assumes that most of the information to
create XML court documents will come from human authors -- lawyers, judges,
clerks, paralegals, and legal secretaries -- rather than from machine sources,
such as databases. It further assumes that authors will create documents that
communicate, explain, argue, clarify, and decide legal issues and concepts
arising in a specific case, and that such documents will not be readily reusable
in
other contexts or cases. This standard also assumes that the basic structures of
ordinary grammar - the sentence and paragraph (as opposed to a comprehensive
set of data elements) - are the preferable containers for text expressing legal
ideas and concepts in XML court documents. Consequently, to promote ease of
use, the Court Document 1.1 DTD offers a relatively
small set of XML elements and attributes, strives for consistency and
intuitiveness with respect to element and attribute names, favors parallel
design of XML tags used for marking up similar content, and seeks to avoid
requiring choices that might be confusing. A simplified Court Document
1.1 DTD also is offered as a further effort to realize these goals.

A fundamental characteristic of XML markup is that it explicitly distinguishes
the use of markup to describe the structure and semantic content of a document
from information describing the way the structured document will be displayed
to a reader. This separation of content from display is often troublesome for
human authors accustomed to controlling the appearance as well as the content
of a document. Authors using modern "what-you-see-is-what-you-get" word
processors are able to impose structure on a document by changing the
appearance of the text. They may underline or italicize words for emphasis or
use different fonts or indentation (white space) for headings, titles, or
subparts of a section or paragraph. The display format an author uses imparts
structure by changing the appearance of the text in ways that a human reader,
but not a machine, can more or less reliably understand.

In contrast, structured markup languages, such as XML, use named elements
instead of font changes, indentation, and the like to describe the structure
and semantics of the text in a document. The markup tags (rather than
formatting) impart structure. For example, the XML element
<documentTitle/>
describes the text it contains as a document title, but says nothing about
the font or spacing that should be used to display it. Structured markup,
however, makes it possible for software to interpret and process documents for
many different purposes. Software applications can reliably retrieve and
process text information from structured documents in predictable, useful ways.
For instance, it is possible to publish the contents of a structured document
in a wide variety of formats, such as HTML, print, braille, or even audio
using exactly the same source document.

Because XML documents separate information about content and structure from
information about display, a separate tool called a stylesheet is typically
used to display the structured form. Information regarding the fonts, margins,
indentation and the like for displaying the structured document is collected
and contained in the stylesheet. Many XML-capable web browsers and other
applications use
Cascading Style Sheets ("CSS")
or stylesheets written in the
eXtensible Stylesheet Language ("XSL")
for this purpose. For example, a stylesheet can contain information regarding
the font style, font size, and indentation for displaying the contents of a
<documentTitle/>
element.

This standard assumes that stylesheets usually will be used to display the
contents of XML court documents to readers, and the samples in the
appendices to this document include sample stylesheets for purposes of
illustration only. The Court Document 1.1 standard does not attempt to
establish any standard stylesheets for displaying the contents of XML court
documents. It does assume, however, that XML elements
for describing the structure and contents of court documents should permit such
documents to be displayed by stylesheets in a form substantially similar to the
paper court documents with which human readers are familiar. It is assumed that
a court or agency may develop standard stylesheet(s) to display the contents of
XML court documents using margins, fonts, indentation, etc. in the way the
court prefers. This standard also assumes that an author may include a
stylesheet
with an XML court document as an attachment if there is a need or desire to
include display information. A receiving application will then need to extract
the
stylesheet and apply it to the XML content for purposes of display.

1.3.2 Assumptions about Court Documents

"Court documents" generally are the category of documents filed with courts or
administrative agencies in formal legal proceedings, such as civil or criminal
lawsuits or administrative hearings. Court documents consist of documents such
as pleadings, orders, briefs, motions, and similar items. They also include
documents related to the case that may never actually be filed in a court, such
as discovery documents, disclosure statements, and offers of judgment. This
standard assumes that court documents possess certain common features in
terms of their basic organization and structure. It also assumes that the basic
organization and structure of information in court documents can be described
using XML elements and attributes.

The Court Document 1.1 DTD proposes standard XML elements and attributes and
content models for using XML to mark up court documents from the widest
possible range of jurisdictions. Its content models are derived primarily from
the information and structures found in paper court documents. In this regard,
the Court Document 1.1 DTD is basically "document-centric" as opposed to
"data-centric" (although information in some parts of a court document, such as
a case caption, is certainly "data-centric").

Court documents not only share a general structure -- they typically contain
technical legal terms and concepts and various types of data interspersed
thoughout the body of the document as phrases, quotations, citations, lists,
and the like. These technical legal terms and concepts and other data, such as
names, addresses, and dates, can be described and categorized in many different
ways. It is possible in concept to define XML mark up tags to describe
technical legal terms such as "due process", "burden of proof," "malice," or
"estoppel" when they appear in XML court documents. As a practical matter,
however, different areas of legal practice use their own particular
vocabularies.

Criminal, domestic, immigration, real estate, tax, and similarly "specialized"
areas of legal practice use scores of special legal terms to communicate
substantive and procedural legal concepts typically having precise technical
meanings for those who practice or work in those fields. Coming up with a
comprehensive set of XML tags for marking up all the technical legal terms and
concepts that can appear in a court document would presumably require hundreds
of XML tags, which would result in a large and complicated DTD. A large and
complicated DTD is likely to be more difficult to learn and
use. Completing the extensive data dictionaries that would be needed might take
years. Thus, the Court Document 1.1 DTD does not attempt to define XML markup
for comprehensive "data sets" of all the specialized legal terms and concepts
that might appear in a court document, although it contemplates that they may
emerge over time.

The Court Document 1.1 DTD marks a beginning by describing the general
organization and structure of information in court documents. It also includes
some general tags for marking up phrases, quotations, lists and similar items
typically appearing in the body of court documents. This standard assumes,
however, that more specialized XML vocabularies used in particular areas of
legal practice will be developed over time and that a means should be provided
to allow authors to mark up specialized legal terms and phrases within XML
court documents. The Court Document 1.1 DTD itself does not attempt to
establish a comprehensive XML vocabulary for describing and categorizing all
the specialized substantive and procedural legal terms that can appear as data
in a court document -- it simply provides a basic framework and general
starting point from which further development can proceed. For example, it is
assumed that a standard XML or other schema for validating XML court documents
will be developed in addition to or as a replacement for the Court Filing 1.1
DTD.

The Court Document 1.1 DTD and the Legal XML Court Filing 1.1 DTD serve
different though related purposes. The Court Filing 1.1 DTD defines data
elements needed for
the electronic filing of various types of electronic documents by court case
management systems. It provides a standard XML vocabulary to describe the data
required for electronic court filing and the structure of that information. In
this regard, it uses XML to promote data interchange with court case management
systems and their accompanying data bases. However, it does not include
information regarding the contents or structure of any pleading or other court
document.

The Court Document 1.1 DTD in contrast defines XML elements and attributes for
marking up the contents and structure of court documents. It defines
information useful for document management systems, for stylesheets to display
XML court documents to human readers, for basic textual analysis of court
documents, and other purposes, possibly including the automated generation and
processing of
some court documents. However, it does not include all the information needed
for the electronic filing and docketing of a pleading or other court document
in a case management system. It assumes and expects that XML court
documents will not be electronically filed directly with a court, but by
means of applications implementing the Court Filing 1.1 standard.

This standard assumes that XML court documents, when included within XML
electronic filings conforming to the Court Filing 1.1 standard, will be base-64
encoded text or unparsed character data. The Court Filing 1.1 DTD contains a
<documentContent/>
element having a #PCDATA content model which can contain a hyperlink, a
base-64 encoded BLOB (particularly useful when the document being filed is a
binary file), or text. An obvious problem with simply placing any XML content,
XML tags and all, directly inside the Court Filing 1.1
<documentContent/>
element is that this will cause validation errors. An XML validating parser
will recognize that the Court Filing 1.1 DTD permits only parsed character data
(text that does not contain any XML delimiters) to occur within the
<documentContent/>
element, but not any XML tags. Consequently, any XML document, including an
XML court document, needs to be base-64 encoded for inclusion in a Court Filing
1.1 XML filing to avoid validation errors. Base-64 encoding removes the <
and & characters and other XML delimiters recognized as such by the parser.

Alternatively, it also is possible to include an XML document, XML tags and
all, within a
<![CDATA[
(unparsed character data) section within the
<documentContent/>
element. Marking a section of text as CDATA in effect turns off the parser so
that the presence of XML delimiters in element tags will not trigger parsing
errors. The proposed Court Document 1.1 DTD assumes that it will be possible to
include XML court documents within XML Court Filing 1.1 filings using either of
these techniques without creating any compatibility problems. Of course, XML
court documents will then need to be extracted from the Court Filing 1.1 XML
filing for further processing.

The Court Document 1.1 DTD also favors consistency with the Court Filing 1.1
XML standard from which it borrows heavily. Many of the XML elements and
attributes in the Court Filing 1.1 DTD, particularly those that contain only
text data, are common to elements and attributes in the Court Document 1.1 DTD.
Such elements from the Court Filing 1.1 DTD have been fully incorporated in the
Court Document 1.1 DTD to the extent they are consistent with the goals of
simplicity, consistency, and flexibility favored by the Court Document 1.1 DTD.

However, not all elements specified in the Court Filing 1.1 standard have been
included in the Court Document 1.1 DTD. A few have been modified to promote the
goals of simplicity, consistency, and flexibility to make the Court Document
1.1 DTD easier to use. Such modifications and the rationale
for them are noted where they occur. When discrepancies between element content
models in this standard and the Court Filing 1.1 element content models exist,
this standard applies only with respect to XML court documents.

1.3.4 Relationship of the Court Document 1.1 DTD with Other XML DTDs.

The Court Document 1.1 DTD employs some of the techniques used in other "open
source," document-oriented XML DTD's, such as the
DocBook
(used for technical documents) and
TEI
(used for scholarly analysis of electronic texts) DTD's. However, other
document-oriented DTD's, even in their simplified forms, are somewhat
complicated and would require substantial modification to be useful for marking
up court documents. Thus, the Court Document 1.1 DTD does not attempt to achieve
compatibility with any other DTD besides the Court Filing 1.1 DTD .

To provide XML mark up tags for describing metadata about XML court documents,
the Court Document 1.1 DTD uses elements based on the
Dublin Core Metadata Element Set, Version 1.1
. The Dublin Core Metadata Initiative (DCMI) is an organization dedicated to
promoting the widespread adoption of interoperable metadata standards for
describing resources that enable more intelligent information discovery
systems. Thus, the Court Document 1.1 DTD incorporates an available standard
for marking up document metadata instead of offering its own metadata tags.

1.3.5 XML Namespaces and the XML Court Document 1.1 DTD.

One fundamental weakness of DTD's is their inability to readily accomodate the
use of
XML namespaces
, which became a standard after the emergence of the XML 1.0 standard. XML
namespaces provide a way to preserve the uniqueness of XML element and
attribute names using Uniform Resource Identifiers ("URI's"). XML namespaces
make it possible for an XML document to use elements and attributes from
different domains without the confusion that would result if an XML element
from one domain had a different content model, but the identical element name
as (and thus "collided" with), an XML element from a separate domain. XML
namespaces solve this problem by permitting prefixes that can be resolved to
URI's to be affixed to element and attribute names.

Unfortunately, changing an XML element or attribute name declared in a DTD by
affixing a namespace prefix makes a document invalid against the DTD. A
validating parser will not recognize the new element name containing the
namespace prefix since the prefixed element is not declared in the DTD and will
not validate the XML document containing it.

One theoretical way to handle this difficulty is by declaring two DTD's - one
without XML
namespaces and another one with XML namespaces. The Court Document 1.1 DTD does
not adopt this solution and does not declare or use XML namespaces with its
elements and attributes. However,
when the use of an XML namespace with Court Document 1.1 XML elements or
attributes is desired (for example with XML documents validated against an
XML Schema
rather than a DTD), the XML namespace URI
"http://www.legalxml.org/ns/courtdocument11.dtd" must be used and the namespace
prefix "cd:" may be used. For example, if an XML namespace is used with the
XML elements and attributes defined in this DTD, the Court Document 1.1
element
<courtDocument/>
would become
<cd:courtDocument xmlns:cd =
"http://www.legalxml.org/ns/courtdocument11.dtd"/>
.

1.3.6 Customizing the Court Document 1.1 DTD

In general, it is not particularly easy to customize a DTD and maintain its
compatibility with existing documents. Changing the repetition, omissibility,
or alternation of elements in a DTD may make existing documents invalid against
the modified DTD. To preserve compatibility with existing documents, keeping
the following principles in mind may be helpful:

changing the repetition of an element from non-repeatable to repeatable will
be backward-compatible with existing documents, but changing from repeatable to
non-repeatable will not;

changing the omissibility of an element or attribute from required to
optional will be backward-compatible with existing documents, but changing from
optional to required will not; and

adding new elements (or parameter entities) as alternatives to existing
elements or as optional items will be backward-compatible with existing
documents, but removing an element as an alternative or adding a new required
element will not.

Extensions are allowed to this standard. All extensions must be readily
identifiable by conforming applications. Conforming applications that do not
understand the extension may ignore the extended element and its content. To
permit extended elements to be readily identified, the Court Document 1.1 DTD
follows the same convention used in the Court Filing 1.1 DTD. Extensions must
be identified by the appearance of an underscore character, "_", at the end of
the new element name. Following the underscore, there shall be a series of
characters identifying the individual or organization creating the extension.
Thus, it would be possible to add a new
<province_legalxml/>
element as an optional alternative to the
<state/>
element in the Court Document 1.1 DTD without affecting the validity of older
documents.

The Court Document 1.1 DTD uses a special element that can contain any other
element declared in the DTD (including new elements) -- the
<addIn/>
element. The
<addIn/>
element can appear only within paragraphs or within the
<machineData/>
element of an XML court document. Because the
<addIn/>
element has an ANY content model, it can contain any of the other elements
declared in the Court Document 1.1 DTD. ANY permits authors to include and use
new elements in the DTD. For example, a "legalTerm" element can be added to the
DTD by adding the element declaration "< !ELEMENT legalTerm_legalxml
(#PCDATA)>." The new
<legalTerm_legalxml/>
element can then be used within an
<addIn/>
element as follows:
<addIn>
<legalTerm_legalxml/>
</addIn>
. Alternatively, it also is possible to add new parameter entities containing
entire "modules" of new optional elements and content models to the DTD and
then to use any of the new elements within an
<addIn/>
element. The ANY content model can be useful in the early stages of DTD
development because it completely opens up the element content models in the
DTD. As a DTD matures, however, the use of ANY can become a detriment, because
new markup added to the DTD may be meaningless to applications created to
process existing XML documents.

1.3.7 Specific Assumptions and Requirements.

The proposed Court Document 1.1 DTD is based on the following specific
assumptions and requirements:

a balance between keeping to a minimum the number, complexity and types of
XML elements or attributes used for marking up XML court documents and the
specific needs of a particular task or function; and

content models that foster good modular component application development in
terms of structure, parent and child elements, and XML vocabulary, with similar
element types constructed and grouped in terms of their content models and
attribute definitions.

The Court Document 1.1 XML standard should provide XML markup to describe
the structure of legal court documents, typically pleadings, orders, briefs,
discovery documents, and the like filed in lawsuits or formal administrative
hearings or associated with lawsuits or hearings and having the following
required, but not exclusive, characteristics:

metatags to hold metadata describing the court document, such as the document
type, document identifier, creator, submitter, subject, version, and other
similar information;

a case caption for information about the court in which a case is pending,
the parties, their attorneys, judicial officials, the case number, and similar
information found in case captions of traditional paper court documents;

a place and means to describe information about electronic signatures used to
sign an XML court document, including the type of electronic signature
technology used, and optionally, for affixing digital signatures and creating
electronic notarizations for self-authenticating XML court documents;

the organization of the contents of the body of the court document into basic
structural components of paragraph groups and paragraphs and XML elements
generally describing their contents, including lists, phrases, quotations,
footnotes, multimedia objects, and similar content; and

a means for incorporating attachments, which may be XML or non-XML documents,
such as binary files.

The Court Document 1.1 XML standard also should provide the following
additional characteristics:

extensibility of the content model of the body of a document, and a means for
making improvements to the content model of the body of a document as elements
specific to specific areas of legal practice are identified and defined;

consistency with the Court Filing 1.1 standard, particularly with respect to
XML element and attribute names and content models for marking up similar
information, while providing different element and attribute names where the
content models are not identical to those in the Court Filing 1.1 standard;

compatibility with the Court Filing 1.1 standard for the electronic filing of
XML court documents by applications implementing the Court Filing 1.1 standard;

elements and attributes for citing or incorporating by reference other XML
and non-XML content, including but not limited to filed court documents;

a means for allowing the encryption of all or portions of atomic XML court
documents
ordered to be sealed or filed under seal by a court; and

a means for displaying a court document as the author intended at the time
that the author finalized it.

2. DTD Specification

The Court Document 1.1 DTD defines the general entities, parameter entities,
elements and attributes used in marking up XML court documents. XML documents
containing elements, attributes, or content models not defined in the Court
Document 1.1 DTD will not be valid against the DTD. Validation against the DTD
essentially helps to assure that a document contains the information an
application needs, in a form the application will accept, to process the
document. Validation against a DTD will not reveal all the erroneous data in an
XML document. For instance, it will not detect typos or misspellings, and it
will not verify the accuracy of information, such a person's birth date,
provided by an author. However, validation against a DTD is a useful step to
assure that an XML document is not missing information important for a
processing application.

The Court Document 1.1 DTD broadly organizes the information in an XML court
document into six basic parts -- document metadata, case metadata, the document
body, signature information, the certificate or proof of service, and
attachments. An optional
<electronicSignature/>
element is also provided for describing information about the electronic
signature technology used to electronically sign an XML court document. Certain
information within the document metadata, case metadata, and document body
portions of an XML court document must always be present in order for a court
document to be valid against this DTD, but the signature, proof of service, and
attachment portions are optional. Each of these basic parts uses its own child
elements and content models to describe the information it contains.

The Simplified Court Document 1.1 DTD omits a number of the elements and
attributes present in the full Court Document 1.1 DTD in order to provide a
somewhat simpler set of elements and content models. For instance, it omits the
%common.attributes
parameter entity,
<nickname/>
,
<partyGroup/>
, paragraph subgroup,
<machineData/>
, and identification elements present in the full Court Document 1.1 DTD. It
also simplifies the
<caseTitle/>
element and omits the
<telephone/>
and
<fax/>
(but not the
<fullTelephone/>
or
<fullFax/>
) elements. It does not contain a
<notarization/>
element and omits some other mark up tags that are not likely to be used
in most XML court documents. The aim is to provide a simplified DTD that can be
used for validating basic XML court documents which do not require the richer
markup provided by the full Court Document 1.1 DTD. Documents valid against
the simplified DTD will be valid against the full DTD, although the reverse will
not always be true.

2.1. DTD Specification

2.2 Character Entities

General entities declared in the Court Document 1.1 DTD and simplified Court
Document 1.1 DTD are listed in
Appendix A
and are derived from the corresponding ISO 8879 standard entity set as
incorporated in the
Simplified DocBook DTD v4.1.2.5
. The general entities
permit various characters such as the section, paragraph, currency signs,
fractions, and other symbols and signs to be used within XML court documents.
For instance,
&para;
can be used in an XML court document for the paragraph symbol and
&sect;
can be used for the section symbol. The character entities are declared at the
beginning of the DTD and can be used at any point within an XML court document.

2.3 Parameter Entities

The proposed XML Court Document 1.1 DTD liberally uses parameter entities to
declare standard content models for many of its elements and attributes. The
use of parameter entities permits the elements and attributes to be organized
within the DTD in a more modular way and also makes customizing and extending
the DTD easier. Using parameter entities in a DTD makes it easier to maintain,
customize and extend the DTD without requiring that the DTD be entirely
re-written. A new parameter entity "module" can be declared that contains the
new elements or new content models. The new parameter entity can then be added
to the DTD as an alternative to or replacement for the one affected by the
changes or to make new elements or attributes available for use.

When internal parameter entities are used to declare a standard content model
in a DTD, the standard content model then can be referred to later in the DTD
simply by a reference to the internal parameter entity. This avoids the need to
repeat the full content model within the DTD. For instance, if there is a group
of standard attributes that can be used with a number of different elements in
the DTD, the standard attributes can be declared once in one parameter entity.
Then the declaration for elements using that group of standard attributes can
simply refer to the parameter entity. In this sense parameter entities are
re-usable modules of mark up that can be applied at various places in the DTD.

Using parameter entities also makes it possible to "flatten" and simplify the
hierarchical organization of elements in a DTD. Instead of using a "container"
element to hold additional elements at a second "tier," the additional elements
can be collected in a parameter entity. When needed, the collection of elements
can be declared simply by referring to the parameter entity and avoiding the
need for a higher tier element to contain them. As a general rule, a "flatter"
DTD contains fewer elements, which makes it easier to learn and
use. The parameter entities in the Court Document 1.1 DTD are intended to serve
that goal.

The parameter entities in the Court Document 1.1 and simplified Court Document
1.1 DTD's are declared after the general entities. Primarily, they describe the
content models for the names and contact information of people and
organizations; document and case metadata elements; elements used in paragraphs
and paragraph groups, signatures, and attachments; and attributes common to
various elements in the DTD.

2.3.1.
% paragraph.model Parameter Entity

< !ENTITY
% paragraph.model ;
"paragraphTitle?, paragraph"
>

Parameter entity for the content model for a paragraph. This content model
provides that an optional paragraph title, if used, must precede the primary
text or body of a paragraph. The paragraph title must immediately precede the
paragraph for which it is the title.

Parameter entity for the content model of a paragraph group. This content model
provides that an optional paragraph group title, if used, must immediately
precede either one or more first-level paragraph subgroup(s) or, alternatively,
one or more combinations of an optional
<paragraphTitle/>
element immediately followed by a
<paragraph/>
element. An author must choose whether to use paragraph subgroups or simply to
use paragraphs.

2.3.3.
% dateTime Parameter Entity

< !ENTITY
% dateTime.content
"date , time?"
>

Parameter entity for the date and time content model. The date and time
elements are used for marking up date and time information in a court document.
Placing these elements together in a parameter entity makes it easier to reuse
them as a group without an additional hierarchical container element such as
the
<dateTime/>
element in the Court Filing 1.1 DTD.

In paper court documents, date information is expressed in a variety of ways,
such as numerical values in mm/dd/yy, dd-mm-yy, or similar formats. Dates also
may be spelled out in text. For purposes of this standard, authors can use the
<date/>
element to mark up date information as a text string in whatever format they
desire. However, to make date information consistently machine readable and
available to applications, dates must also be expressed as numbers within the
required
"date"
attribute. To provide consistency and in keeping with the Court Filing 1.1
DTD, date and time information in the required attributes must follow the
standards set by ISO 8601 (the ISO standard for numerical date/time interchange
formats). Specifically, date information in the
"date"
attribute must be expressed numerically using the Gregorian Calendar and the
form ccyy[-mm[-dd]]. All components shall be zero-padded to two digits and
should be hyphenated -- for example
<date date=" 2002-05-31">May 1, 2002</date>
.

Similarly, time information in the required
"time"
attribute of the
<time/>
element must be expressed in Coordinated Universal Time (UTC), using the form
hh[:mm[:ss[:ttt]]]Z. For example,
<time time = "22:04:38.015Z">10:04:38 pm</time>
represents thirty-eight and 15 thousands seconds after 10:04 PM. A Z shall be
appended to the end. ISO 8601 uses this convention to express times in UTC. All
components must be zero-padded to two digits.

Parameter entity for the content model for the name of a person. This content
model requires authors to choose whether to mark up the full name of a person
optionally followed by alias names, the person's alias name alone, or the
person's last name (together with separate first and middle names, name
prefixes, suffixes, aliases, and nicknames, which are optional) depending on
the degree of detail desired. In requiring authors to provide at least one form
of a person's name, this content model differs from, but does not collide with,
the comparable content model of the
<personName/>
element in the Court Filing 1.1 DTD which makes all elements of a person's
name optional. Placing these elements in a parameter entity simplifies the DTD
by eliminating the need for additional hierarchical container elements such as
the
<name/>
and
<personName/>
elements in the Court Filing 1.1 DTD.

Parameter entity for the content model for organization names. This content
model requires authors to choose whether to provide the organization's name
optionally followed by the name of a division (or department), and allows the
optional choice of an alias name, acronym, or abbreviated name. Alternatively
it also permits authors to mark up just a single abbreviated, acronym or alias
name for the organization. In requiring authors to provide at least one form of
an organization's name, this content model differs from the comparable content
model of the
<organizationID/>
in the Court Filing 1.1 DTD which contains different child elements and makes
all of them optional. Placing these elements in a parameter entity simplifies
the DTD by eliminating the need for additional hierarchical container elements
such as the
<name/>
,
<entity/>
and
<organizationID/>
elements in the Court Filing 1.1 DTD.

2.3.6.
% role.content Parameter Entity

< !ENTITY
% role.content
"roleName+ , roleWith*"
>

Parameter entity for the role content model. This content model permits authors
to mark up text describing the roles of a person or organization and optionally
allows a reference to associated persons or organizations. This content model
is identical to the content model of the
<role/>
container element in the Court Filing 1.1 DTD.

Parameter entity for contact information for a person or organization. This
content model allows authors the options of providing multiple postal
addresses, phone and fax numbers, email addresses, and uri addresses. If
contact information is provided, the various items must be given in the
sequence listed. This content model is similar to, but differs somewhat from,
the organization of elements used in the
<actor/>
element in the Court Filing 1.1 DTD for describing contact information. For
one thing, this parameter entity groups together and "modularizes" elements
describing contact information. Additionally, it includes elements for full
telephone or full fax numbers as well as a
<uri/>
element, which are not present in the comparable content model in the Court
Filing 1.1 DTD.

Parameter entity for identification information for a person. This content
model allows authors optionally to mark up multiple identification numbers for
a person, to provide either a person's birth date or age, or to include
multiple text comments identifying or uniquely describing a person. Elements in
this parameter entity are derived from elements in the
<personDescription/>
element in the Court Filing 1.1 DTD. However, for purposes of simplifying this
DTD, none of the elements from the Court Filing 1.1 DTD for marking up the
physical characteristics of a person are included.

Parameter entity for identification information for an organization. This
content model allows authors optionally to mark up multiple identification
numbers for or to include multiple text comments identifying or uniquely
describing an organization. This parameter entity is based on the
%personIdentification.content;
parameter entity. It provides consistency in the content models used to
describe identification information for persons and organizations.

Parameter entity for the postal address content model. This content model
requires authors to choose whether to mark up detailed address information or
to provide only a full address. If detailed address information is provided,
each of the individual items is optional, but when used they must be given in
the sequence listed. The content model of this parameter entity is virtually
identical to the content model of the
<postalAddress/>
container element in the Court Filing 1.1 DTD, except that the
<addressFull/>
element name has been changed to
<fullAddress/>
for greater consistency with other similarly named elements in this DTD.

Parameter entity for the document metadata content model. This parameter entity
holds elements to describe metadata about a court document that may be used by
document management applications. Most of the elements in the document metadata
parameter entity are based closely on the version 1.1 Dublin Core Metadata
Element Set for describing metadata (see
http://dublincore.org/documents/dces/
for details). An author must provide information for the
<dateTimeCreated/>
,
<documentType/>
,
<creator/>
,
<submitter/>
, and
<format/>
elements. The remaining elements are optional. Document metadata provided must
be given in the sequence of the listed elements. The Court Filing 1.1 DTD does
not contain a comparable content model for document metadata.

The
<documentTitle/>
element is optional in this content model, and it is a required element in the
content model for the
<caseMetadata/>
element. If used in the
<documentMetadata/>
element, the contents must be identical to those of the
<documentTitle/>
element in
<caseMetadata/>
in order to avoid providing two different document titles for the same
document.

2.3.12.
% tribunal.content Parameter Entity

< !ENTITY
% tribunal.content
"court | agency"
>

Parameter entity for the content model of the tribunal in which a case or
proceeding is pending. An author must choose whether the tribunal is a court or
an agency.

Parameter entity for case metadata regarding the case in which the document is
filed or served. Metadata about the case in which a court document is filed
customarily appears in the caption at the beginning of a paper court document.
Information identifying the tribunal (court or agency) in which the case is
pending must be provided. The
<fullCaseNumber/>
and
<caseTitle/>
elements are optional. The
<documetTitle/>
element is required, and also is an optional element in the content model for
document metadata.

Additionally, multiple
<relatedCase/>
elements may be included to describe information about related cases that have
been consolidated, transferred, appealed, etc. The content model declared in
this parameter entity is somewhat comparable to, but simpler than, the content
models in the
<caseInformation/>
and
<courtInformation/>
container elements in the Court Filing 1.1 DTD. Thus, this parameter entity
has been given a different name.

Parameter entity for the contents of a paragraph. The
<paragraph/>
element is the basic container of text information in the body of a court
document and serves as the basic container for text expressing a thought or
argument of an author. It has a mixed content model (i.e. it can hold text and
subelements). The subelements that an author can use to mark up particular
items of information within a paragraph are described in this parameter entity.

2.3.15.
% signers.content Parameter Entity

< !ENTITY
% signers.content
"signatory+ , notarization?"
>

Parameter entity for describing the signers of a court document. This content
model requires authors to provide signatory information for one or more signers
optionally followed by a notarization. This information is not intended to
serve as an electronic signature. Markup to describe information about
electronic signatures used to sign an XML court document, including the type of
electronic signature technology used, is provided in the
<electronicSignature/>
element.

Parameter entity for the content model for signatory information. This content
model requires authors either to mark up one or more signature lines followed
by information about one or more signatories or to mark up information about a
signer followed by one or more signature lines depending on the sequence
desired. These elements permit markup of the text appearing as a signature in
paper court documents, but are not intended to affect the validity or
invalidity of a digital signature electronically affixed to an XML court
document.

Parameter entity for the content model of a certificate of service. A
certificate of service must contain one or more paragraphs (each of which may
be optionally preceded by a paragraph heading), the date (and time, if desired)
the document was served, and information about the signer of the certificate of
service. The information must be provided in the sequence described.

Parameter entity for attributes of elements used for marking up text content
in the body of a court document. Each of these attributes is optional, but
authors may use any or all of them to provide a more detailed description of
a particular item of content in the body of a court document, such as a
paragraph group, paragraph, subparagraph, phrase, or list. The
"label"
attribute can contain a label, such as a number or letter designation, for the
content item. The
"type"
attribute can contain a description of the category, genre, or nature of the
item of content. The
"subject"
attribute can contain comma-separated keywords or key phrases describing the
topics addressed in the content item. The
"language"
attribute describes the language of the content item using a two-letter
language code (taken from the ISO 639 standard) and can be used to identify
phrases, paragraphs, or other content items of a different language. The
"privacy"
attribute is an enumerated attribute indicating whether the content item
should be sealed or redacted.

Parameter entity for the common attributes defined in the Court Filing 1.1 DTD
for use with certain data elements common to law, safety, and justice
applications. Because some elements in this DTD are data elements incorporated
from the Court Filing 1.1 DTD, these common attributes also are included in
this DTD for closer compatibility. This approach provides that elements
appearing in both DTD's will have the same content models.

As described in the Court Filing 1.1 standard,
"id"
provides a means to identify a specific element in an XML document;
"type"
provides a means to describe the type of information being provided,
"status"
provides a place to describe the status of this information,
"referenceDate"
identifies the date on which the status was known to be accurate, and
"codeSource,"
"codeValue,"
and
"codeLiteral"
are used to identify the appropriate code source (usually a formal standard),
along with both the coded and literal forms of the data.

Parameter entity for attributes from the W3C's
XML Linking Language (XLink) Version 1.0 Recommendation
used to create an XML linking element. The default attribute values are for a
simple XML link. The XLink attributes are used with the
<link/>
and
<image/>
elements in the Court Document 1.1 DTD. The
xlink:type
attribute describes the type of link -- the default is 'simple.' The required
xlink:href
attribute contains the URI for the linked resource. The optional
xlink:role
and
xlink:title
attributes contain information about the role and title of the target
resource. The
xlink:show
attribute contains information for displaying the linked resource when the
link is activated, such as by replacing the contents of the current window. The
default value is 'replace.' The
xlink:actuate
attribute suggests when the link should be activated, such as only after a
specific user request.

Parameter entity for the U.S. Postal Service (USPS) abbreviations for U.S.
states. Postal abbreviations are declared in the DTD so that authors do not
have to incorporate them from a separate source and to avoid potential problems
from the use of inconsistent abbreviations.

2.4 Elements and Attributes.

The elements and attributes in the Court Document 1.1 DTD are declared and
organized in the following groups: common elements used throughout a court
document
to describe the names, contact information, and roles of the participants in a
legal proceeding (e.g. attorneys, judicial officers, witnesses, parties, etc.);
elements for describing document metadata; elements for describing case
metadata (e.g. information usually found in the captions of paper court
documents); elements for marking up the textual content of the body of a court
document; elements for describing information about the signer(s) of a court
document; elements for marking up a certificate of service; and elements for
describing attachments. An optional element is also included for electronic
signature information. An alphabetical list of the elements declared in the
Court Document 1.1 DTD is included as
Appendix B
.

2.4.1. Common Elements to Describe Names, Contact, Role, Date and Time, and XML
Linking Information.

The Court Document 1.1 DTD contains a group of "common" elements for describing
name, contact, role, date and time, and XML linking information. Most of these
common elements describe information about the people and organizations
typically involved in lawsuits or administrative hearings, such as parties,
attorneys, judicial officers, law enforcement officers, witnesses, and the
like. Participants in a legal proceeding customarily are referred to and
thought of
in terms of their general roles in a proceeding (e.g. as a party, an attorney,
a witness, and so forth). As described elsewhere in more detail, the Court
Document 1.1 DTD includes separate elements for describing information about
these and other participants in legal proceedings with the goal of making the
DTD
more intuitive, and it uses "common" elements and content models consistently
within those elements to describe name, contact, and role information. In
taking this
approach, the Court Document 1.1 DTD differs from the Court Filing 1.1 DTD,
which uses only a single, generic
<actor/>
element for a comparable purpose.

Additionally, the content model for the
<actor/>
element in the Court Filing 1.1 DTD contains several dozen XML elements for
describing a wide range of information about both the people and the
organizations involved in a case. A comprehensive set of elements is important
for promoting data interchange using XML, but there is less need for a
comprehensive set of elements to markup the more limited information about
people or organizations typically appearing in the documents actually filed or
served in a lawsuit or administrative proceeding. Thus, the Court Document 1.1
DTD seeks simplification by reducing both the
number of "common" elements used for describing name, contact, and role
information and the choices required to mark up such information.

However, many of the elements used in the Court Filing 1.1 DTD to describe
name, contact, role, and other information can easily be used to mark up the
same information in XML court documents. Consequently, for consistency the
Court Document 1.1 DTD incorporates from the Court Filing 1.1
<actor/>
element many "horizontal" common elements and content models for describing
the names, contact information, and roles of various participants. The Court
Document 1.1 DTD uses a smaller set of common elements to describe such
information and organizes them to promote ease of learning and ease of use. As
previously noted, it uses these "common" elements to form substantially similar
and consistent content models within more descriptive "role" elements
describing the various participants in a legal proceeding, such as
<attorney/>
,
<party/>
,
<witness/>
, or
<organization>
.

fullName
contains the entire, or complete name of a person, including any prefix or
suffix. It also takes the optional common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is incorporated from
the Court Filing 1.1 DTD.

aliasName
contains the alias of a person or organization. It is not included in the
Court Filing 1.1 DTD. In addition to the
%common.attributes;
, the
"aliasFor"
attribute is a reference to the "id" attribute value of the party, person, or
organization using the alias. The
"aliasType"
attribute is required to indicate the type of the alias name.

nickName
contains the nickname of a person. It is not included in the Court Filing 1.1
DTD.

< !ELEMENT
nickName
(#PCDATA)
>

namePrefix
contains any formal prefix that is used with a person's name, e.g., "The
Honorable", "Mr.", "Ms.". It also takes the optional common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is
incorporated from the Court Filing 1.1 DTD.

firstName
contains the first, or given, name of a person. It also takes the optional
common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is incorporated from the Court Filing 1.1 DTD.

middleName
contains a person's middle name, initials, or multiple initials. Each of the
names of a person between their first and last names are described by this
element. It also takes the optional common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is incorporated from
the Court Filing 1.1 DTD.

lastName
contains the last, or family, name of a person. It also takes the optional
common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is incorporated from the Court Filing 1.1 DTD.

nameSuffix
contains a suffix to a person's name, such as "Jr.", "PhD", or "III". It also
takes the optional common attributes --
id
,
type
,
status
,
referenceDate
,
codeSource
,
codeValue
, and
codeLiteral
. It is incorporated from the Court
Filing 1.1 DTD.

postalAddress
contains the
% postalAddress.content
parameter entity, which in turn contains a content model for describing a
postal location to which paper mail can be directed. This content model is
based on the
<postalAddress/>
element in the Court Filing 1.1 DTD and makes its child elements optional.
However, it includes an additional enumerated attribute
"addressType"
from which authors can indicate the type of postal address information being
provided. An enumerated attribute list of such choices is provided to
standardize the descriptions of postal address types. The content model also
requires authors to choose either the separate elements for an address or a
full address, but not both. This difference, however, does not result in a
collision with the content model used in the Court Filing 1.1 DTD for postal
addresses, which allows either approach.

addressLine
contains text address lines, and may include alternative text for locations
that don't have a postal address system.
<addressLine/>
elements must be sequenced in the order they would appear on an address label.
The attribute
"type"
may be used to identify the context of the address line, e.g., a firm name, a
suite number, street, or post office box. It is incorporated from the Court
Filing 1.1 DTD.

city
contains the name of a city, town, or township. It is incorporated from the
Court Filing 1.1 DTD.

< !ELEMENT
city
(#PCDATA)
>
< !ATTLIST
city
%common.attributes;
>

county
contains the name of a county. It is incorporated from the Court Filing 1.1
DTD.

< !ELEMENT
county
(#PCDATA)
>
< !ATTLIST
county
%common.attributes;
>

state
contains the name of a state or province. This content model is based on the
<state/>
element in the Court Filing 1.1 DTD, but includes an additional enumerated
attribute
"state"
from which authors can select the USPS abbreviation for a U.S. state. An
enumerated attribute list (as set out in the
%state.codes
parameter entity containing the USPS abbreviations for U.S. states) is provided
for
purposes of standardization. This element is substantially consistent with the
Court Filing 1.1 DTD, which provides that USPS abbreviations are preferred for
U.S. states, but uses the
"codeValue"
and
"codeSource"
attributes to indicate the value and source of the abbreviated codes instead
of including them in an enumerated attribute.

fullAddress
contains a complete address. The content model is identical to the content
model of the
<addressFull/>
element in the Court Filing 1.1 DTD, but the element name has been changed for
greater consistency with similarly named elements in this DTD. The
ISO 3166
abbreviations for country names must be used if the country name is
abbreviated.

telephoneNumber
contains the main telephone number. The
"format"
attribute is used to define the format of the digits comprising the telephone
number. Format information includes: the hash ("#") character to indicate the
position of a telephone keypad digit, and white space characters to specify the
position for optional white space. This element is incorporated from the Court
Filing 1.1 DTD.

fullTelephone
contains a complete telephone number. It includes an enumerated attribute
"telephoneType"
from which authors can indicate the type of telephone information being
provided. An enumerated attribute list of such choices is provided to
standardize the descriptions of telephone types. It is not included in the
Court Filing 1.1 DTD.

fax
contains a fax telephone number. It is incorporated from the Court Filing 1.1
DTD.

< !ELEMENT
fax
(telephone)
>
< !ATTLIST
fax
%common.attributes;
>

fullFax
contains a complete fax telephone number. It includes an enumerated attribute
"faxType"
from which authors can indicate the type of fax telephone information being
provided. An enumerated attribute list of such choices is provided to
standardize the descriptions of fax telephone types. It is not included in the
Court Filing 1.1 DTD.

email
contains an email address. It is incorporated from the Court Filing 1.1 DTD,
but includes an enumerated attribute
"emailType"
from which authors can indicate the type of email address being provided. An
enumerated attribute list of such choices is provided to standardize the
descriptions of email address types.

uri
contains either a Universal Resource Identifier (URI) or a Universal Resource
Locator (URL). It is incorporated from the Court Filing 1.1 DTD.

< !ELEMENT
uri
(#PCDATA)
>

roleName
contains the name of the role taken by a person or organization. It is
incorporated from the Court Filing 1.1 DTD.

< !ELEMENT
roleName
(#PCDATA)
>

roleWith
contains a description of the person or organization with which a relationship
exists. It also has an optional
"actorID"
attribute which can point to the
"id"
attribute of other person or organization elements to indicate a relationship
with them. For example, an attorney/client relationship or a relationship
between a person and an organization can be described in this way. This element
is based on the
<roleWith/>
element from the Court Filing 1.1 DTD.

date
contains a text string describing a date. It is incorporated from the Court
Filing 1.1 DTD, but includes two additional attributes. It includes a required
attribute
"date"
for providing date information in ISO 8601 number format (e.g. 2002-05-31) as
noted in the description of the
% dateTime
entity. It also includes the optional attribute
"dateType"
to contain further information describing the category of date information
provided.

time
contains a text string describing a time. It is incorporated from the Court
Filing 1.1 DTD, but includes an additional required attribute
"time"
for providing time information in ISO 8601 number format as noted in the
description of the
% dateTime
entity.

link
contains the information to create an XML link. It uses the global attributes
from the XLink namespace for compatibility with the W3C's
XML Linking Language (XLink) Version 1.0 Recommendation
. The XLink global attributes used by the
<link/>
element are declared in the
%xlink.attributes;
parameter entity and the default attribute values are set to create a simple
link identical to an HTML link. For instance, a simple link to the Legal XML,
Inc. home page would be <link xlink:type="simple"
xlink:href="http://www.legalxml.org" xlink:title="Legal XML, Inc."
xlink:show="replace" xlink:actuate="onRequest">Legal XML</link>.
Although XLink global attributes can be used to make any element a linking
element, they are used only by the
<link/>
and
<image/>
elements in this DTD.

< !ELEMENT
link
(#PCDATA)
>
< !ATTLIST
link
%xlink.attributes;
>

image
is an empty element for an image link using the global attributes from the
XLink namespace for compatability with the W3C's
XML Linking Language (XLink) Version 1.0 Recommendation
. The fixed attribute values of the global XLink attributes create a simple
link for embedding an image and thus are different from the default attribute
values declared in the
%xlink.attributes;
parameter entity. Although XLink global attributes can be used to make any
element a linking element, they are used only by the
<link/>
and
<image/>
elements in this DTD.

2.4.2. Elements to Describe Information about Those Involved in a Court or
Administrative Proceeding.

The Court Document 1.1 DTD classifies information about those typically
involved or mentioned in court documents in two ways. First, it defines two
elements,
<person/>
and
<organization/>
, to reflect the general distinction between human beings on the one hand and
corporations, partnerships, associations, and similar inanimate legal entities
on the other. Information about people is different in some respects from
information about organizations, particularly with respect to name information,
and the content models for these two elements reflect that difference. This
approach is fundamentally different from the approach taken by the Court Filing
1.1 DTD, which uses only a single
<actor/>
element to contain information about both people and organizations.

Second, to make the DTD more intuitive, the Court Document 1.1
DTD defines separate elements describing the particular roles most
frequently taken by those involved in a lawsuit or administrative proceeding.
The names of the "role" elements in this DTD reflect the classifications that
attorneys, judges, clerks, and others who regularly work with court documents
typically use for those involved in a court or administrative proceeding. In
this
respect, the Court Document 1.1 DTD attempts to incorporate element names that
are intuitive and meaningful to those who typically will be authoring XML court
documents. This approach also makes it possible to more predictably
and less ambiguously describe the nature of a particular person's or
organization's involvement in a legal proceeding.

Six of the "role-specific" elements in the Court Document 1.1 DTD --
<attorney/>
,
<judicialOfficer/>
,
<notary/>
,
<administrativeOfficer/>
,
<enforcementOfficer/>
, and
<witness/>
-- are intended to apply only to people. Consequently, each of these elements
contains the same parameter entities, child elements, attributes, and content
models as the more generic
<person/>
element. Two other "role" elements,
<party/>
and
<victim/>
, can refer either to human beings or to organizations. Thus, those two "role"
elements contain child elements and content models for describing information
applicable either to people or to organizations.

person
contains the name, contact, identification, and specific role information for
a person. It uses the content models from the
%personName.content;
parameter entity,
%contact.content;
parameter entity,
<personIdentification/>
element, and
%role.content;
parameter entity. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of a person; all other information is optional. This content model is
loosely based on the content model of the
<actor/>
element in the Court Filing 1.1 DTD.

The
<person/>
element has almost all the attributes of the
<actor/>
element in the Court Filing 1.1 DTD. The optional
"id"
attribute contains a unique identifier for the person. The optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<person/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about a
<person/>
is sealed or redacted.

personIdentification
contains elements to describe information uniquely identifying a person, such
as personal id numbers, date of birth or age, or similar information. It uses
the content models declared in the
%personIdentification.content;
parameter entity. The content model is loosely based on the
<personDescription/>
element in the Court Filing 1.1 DTD, but elements for describing physical
characteristics and other personal information are not included to simplify
this content model.

< !ELEMENT
personIdentification
(%personIdentification.content;)
>

personalIDNumber
contains an identification number assigned by various agencies and
organizations
for a person. It is incorporated from the Court Filing 1.1 DTD. The
"type"
attribute identifies the category of ID number assigned, e.g., "social
security", "driver's license". This element has an additional attribute,
"issuingAuthority"
, which contains the name of the issuing organization or state issuing the
identification number.

birthDate
contains a text string giving the date of birth of a person. It is
incorporated from the Court Filing 1.1 DTD, but the required
"date"
attribute has been added for providing date information in ISO 8601 number
format.

attorney
contains the name, contact, identification, and role information for an
attorney. It uses the content models from the
% personName.content ;
parameter entity, the
% contact.content ;
parameter entity, the
<barNumber/>
element, the
<personIdentification/>
element, and the
% role.content ;
parameter entity. Information about the name of an attorney must be provided;
all other information is optional. This content model is nearly identical to
the content model for the
<person/>
element -- only the
<barNumber/>
element has been added. This element has the same attributes as the
<person/>
element.

barNumber
contains the bar number for an attorney. It is incorporated from the Court
Filing 1.1 DTD, although the attributes
"issuingAuthority"
,
"yearAdmitted"
, and
"barStatus"
have been added. These attributes contain information describing the state bar
issuing the bar number, the year the attorney was admitted to practice, and the
status of the attorney's license. These attributes are based on elements
appearing in the
<barMembershipInformation/>
element of the Court Filing 1.1 DTD, but have been changed to attributes to
simplify this DTD.

judicialOfficer
contains the name, contact, identification, and role information for a judge,
clerk of court, magistrate, or similar judicial official. It uses the same
content models as the
<person/>
element. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of the judicial officer; all other information is optional. The
<judicialOfficer/>
element also has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the judicial officer. The optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<judicialOfficer/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about a
<judicialOfficer/>
is sealed or redacted.

notary
contains the name, contact, identification, and role information for a notary
public. It uses the same content models as the
<person/>
element. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of the notary; all other information is optional. The
<notary/>
element also has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the notary. The optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<notary/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about a
<notary/>
is sealed or redacted.

administrativeOfficer
contains the name, contact, identification, and role information for an
administative law judge, hearing officer, board member or similar
administrative official. It uses the same content models as the
<person/>
element. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of the administrative officer; all other information is optional. The
<administrativeOfficer/>
element also has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the administrative officer. The
optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<administrativeOfficer/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about an
<administrativeOfficer/>
is sealed or redacted.

enforcementOfficer
contains the name, contact, identification, and role information for a police
officer, sheriff, deputy, detective, or similar law enforcement official. It
uses the same content models as the
<person/>
element. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of the enforcement officer; all other information is optional. The
<enforcementOfficer/>
element also has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the enforcement officer. The
optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<enforcementOfficer/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about an
<enforcementOfficer/>
is sealed or redacted.

witness
contains the name, contact, identification, and role information for a
witness. It uses the same content models as the
<person/>
element. The
%personName.content;
parameter entity requires authors to provide the full name, alias name, or
last name of the witness; all other information is optional. The
<witness/>
element also has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the witness. The optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<witness/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about an
<witness/>
is sealed or redacted.

organization
contains the name, contact, identification, and role information for an
organization, such as a corporation, association, partnership, or similar legal
entity. It uses substantially the same content models as the
<person/>
element. However, it uses the
%organizationName.content;
parameter entity instead of the
%personName.content;
parameter entity for name information and the
<organizationIdentification/>
element instead of the
<personIdentification/>
element.

The
<organization/>
element has the same attributes as the
<person/>
element. The optional
"id"
attribute contains a unique identifier for the organization. The optional
"reference"
attribute contains the value of the
"id"
attribute of a fully defined
<organization/>
element appearing elsewhere in the document. The
"privacy"
attribute can be used to indicate whether information about an
<organization/>
is sealed or redacted.

organizationIdentification
contains elements to describe information uniquely identifying an
organization. It uses the content models declared in the
%organizationIdentification.content;
parameter entity. The content model is based on the
<personIdentification/>
element and provides consistency in the content models used to describe
identification information for persons and organizations.

organizationIDNumber
contains identifiers for an organization. The
"type
attribute identifies the category of ID number assigned. This element has an
additional attribute,
"issuingAuthority"
, which contains the name of the authority issuing the identification number.

victim
contains information about a person or organization that is the victim of a
crime. It contains either a single
<person/>
or
<organization/>
child element, and thus incorporates the content models used by those
elements. It has an optional
"id"
attribute.

party
contains information about a person or organization that is a party in the
proceeding. It contains either a single
<person/>
or
<organization/>
child element (and thus incorporates the content models used by those
elements). Information about a party's attorney(s) is optionally contained in
the
<party/>
element to reflect the attorney's relationship with the party.

The
<party/>
element has a required
"partyType"
attribute to describe the particular type of party, e.g. "Paintiff,"
"Respondent," "Third-Party Defendant," etc. A specific description of the
particular role of a party also can be contained in the
<roleName/>
element of the
<person/>
or
<organization/>
elements. The
<party/>
element has an optional
"id"
attribute.

2.4.3. Elements to Describe the Basic Parts of an XML Court Document.

The Court Document 1.1 DTD uses the element
<legal/>
, a generic tag preceding all legal-related XML, as the root element. The
<legal/>
element can contain one or more XML court documents. The information in each
XML court document is organized into six basic parts -- document metadata, case
metadata, the document body, signature information, the certificate or proof of
service, and attachments. The document metadata, case metadata, and document
body portions of an XML court document must always be present in order for an
XML court document to be valid against this DTD, but the signature, proof of
service, and attachment parts are optional. An optional
<electronicSignature/>
element is also provided for electronic signature information.

legal
is the root element of an XML court document and contains one or more required
<courtDocument/>
elements. This generic tag precedes all legal related XML.

< !ELEMENT
legal
(courtDocument+)
>

courtDocument
holds the container elements for the contents of an XML court document. The
<documentMetadata/>
,
<caseMetadata/>
, and
<documentBody/>
elements must be present in the sequence stated. The
<signers/>
,
<proofOfService/>
, and
<attachedItem/>
elements are optional, but must appear in the sequence stated if used. It also
contains an optional
<electronicSignature/>
element which describes information regarding the electronic signature used
for electronically signing the court document(s). The
<courtDocument/>
element has a fixed
"version"
attribute specifying the version number as 1.1.

2.4.4. Elements to Describe Document Metadata.

The Court Document 1.1 DTD uses elements based on the
Dublin Core Metadata Element Set, Version 1.1
to describe metadata about an XML court document. The Dublin Core Metadata
Element Set describes items of metadata useful for describing documents and
other resources to enable more intelligent information discovery systems.

documentIdentifier
is a required element containing an unambiguous reference, typically a string
or number conforming to an identification system, to the court document. The
<documentIdentifier/>
element is substantially similar to the Dublin Core "identifier" element.

< !ELEMENT
documentIdentifier
(#PCDATA)
>

dateTimeCreated
is a required element containing the date and time associated with the
creation or last modification of the court document. The
<dateTimeCreated/>
element is substantially similar to the Dublin Core "date" element and is
based on the
<creation/>
element in the Court Filing 1.1 DTD. It contains the
%dateTime.content;
parameter entity.

< !ELEMENT
dateTimeCreated
(% dateTime.content;)
>

documentTitle
is an optional element containing the title or name given to the court
document. It is optional in this content model, and it is a required element in
the content model for
<caseMetadata/>
. If used in this element, the contents must be identical to the contents of
the required
<documentTitle/>
element in
<caseMetadata/>
in order to avoid providing two different document titles for the same
document. The
<documentTitle/>
element is substantially similar to the Dublin Core "title" element and is
incorporated from the Court Filing 1.1 DTD.

< !ELEMENT
documentTitle
(#PCDATA)
>

documentStatus
is an optional element containing a description of the status of the court
document. The
"draft"
attribute indicates whether the court document is a draft or final version
(the default enumerated attribute value is "draft"). The optional
"privacy"
enumerated attribute indicates whether the court document is sealed or
redacted. The
"specialHandling"
attribute indicates whether special handling of the court document is needed
(the default enumerated attribute value is "yes"). If the
<documentStatus/>
element is not present in a court document, then the court document is
presumed to be a final version which is not sealed or redacted and which does
not require any special handling.

documentType
is a required element containing a description of the nature, category, or
genre of the content of the court document. The
<documentType/>
element is substantially similar to the Dublin Core "type" element and is
incorporated from the Court Filing 1.1 DTD. For consistency with the Court
Filing 1.1 DTD, it takes an optional
"documentCode"
attribute which can contain a specific code describing the type of court
document.

creator
is a required element containing either a single
<person/>
or
<organization/>
element and describes the person or organization primarily responsible for
making the content of the court document.

< !ELEMENT
creator
(person | organization)
>

contributor
is an optional element and may appear multiple times. It contains either a
single
<person/>
or
<organization/>
element and describes a person or organization responsible for contributing to
the content of the court document.

< !ELEMENT
contributor
(person | organization)
>

submitter
is a required element containing information regarding the party, attorney,
judicial officer, administrative officer, enforcement officer, notary, court,
or agency responsible for making the court document available by serving it or
submitting it for filing. The
<submitter/>
element is substantially similar to the Dublin Core "publisher" element.

format
is a required element containing the media type, usually the MIME type
(text/xml), of the court document.

< !ELEMENT
format
(#PCDATA)
>

description
is an optional element containing an abstract or text summary of the contents
of the court document.

< !ELEMENT
description
(#PCDATA)
>

subject
is an optional element containing comma-separated keywords or key phrases
describing the topic(s) addressed in the court document.

< !ELEMENT
subject
(#PCDATA)
>

coverage
is an optional element containing a description of the extent or scope of the
content of the court document, such as the jurisdiction of the court or
administrative agency to which or by which it is submitted.

< !ELEMENT
coverage
(#PCDATA)
>

language
is an optional element containing a description of the language of the court
document. The description of the language must follow
RFC 1766
, which includes a two-letter language code from the
ISO 639-1
standard followed optionally, by a two-letter country code from the
ISO 3166
standard. For example, 'en' for English, 'fr' for French, or 'en-uk' for
English used in the United Kingdom.

< !ELEMENT
language
(#PCDATA)
>

reference
contains links to related documents, images, or other resources or to
documents or other resources from which the contents of the court document have
been derived. The
<reference/>
element is substantially similar to the Dublin Core "relation" and "source"
elements. It can contain multiple
<link/>
or
<image/>
elements. The
<reference/>
element uses optional attributes to provide additional information about a
reference. The optional
"sourceTitle"
attribute contains the name of the referenced resource. The optional
"sourceCreator"
attribute describes the author or publisher of the referenced resource. The
"sourceDate"
attribute contains the date of the referenced resource in ISO 8601 number
format. The
"sourceIdentifier"
attribute contains a string or number unambiguously identifying the referenced
resource and typically conforming to a formal identification system, such as a
URI or ISBN.

2.4.5. Elements to Describe Case Metadata.

Information typically found in captions of court documents, such as the name
and location of the tribunal in which the case is pending, the case number, and
the names of the parties, is contained in the
<caseMetadata/>
element. The content model for this element is described in the
%caseMetadata.content;
parameter entity.

caseMetadata
contains the elements and content model for describing metadata about the case
or proceeding in which the court document is being filed or served. Its child
elements and content model are described in the
%caseMetadata.content;
parameter entity. The
%tribunal;
parameter entity requires an author to identify the tribunal in which the
document is being filed as either a court or administrative agency. The
<fullCaseNumber/>
and
<caseTitle/>
elements are optional, but may occur only once. The optional
<relatedCase/>
element may occur multiple times.

The
<caseMetadata/>
element has an optional
"caseType"
attribute, which can be used to describe the case type. This attribute may
contain the case types described in the Court Filing 1.1 DTD (e.g. civil,
domesticRelations, probate, smallClaims, etc.) or additional case types not
listed in the Court Filing 1.1 DTD (e.g. arbitration, industrialCommission,
etc.).

court
contains the elements and content model to describe the name of the court in
which the case is pending, its venue or more detailed contact information, and
information regarding the judicial officers involved in the case. This content
model requires authors to provide the court's name (optionally followed by a
division, district, or circuit name or an abbreviated name) or just an
abbreviated name of the court. It also requires authors to provide either the
venue of the court (city or county and state) or to provide more detailed
contact information (using the content model of the
%contact.content;
parameter entity previously described). Information about the judicial
officer(s) involved is optionally contained in the
<court/>
element to reflect their relationship with the court. The
<court/>
element also has an optional
"courtType"
element to describe the general category or level of the court.

courtName
is a required element containing the name of the court in which the case is
pending. It is incorporated from the Court Filing 1.1 DTD.

< !ELEMENT
courtName
(#PCDATA)
>

courtDivision
is an optional element containing the name of the division of the court in
which the case is pending.

< !ELEMENT
courtDivision
(#PCDATA)
>

courtDistrict
is an optional element containing the name of the district of the court in
which the case is pending.

< !ELEMENT
courtDistrict
(#PCDATA)
>

courtCircuit
is an optional element containing the name of the circuit of the court in
which the case is pending.

< !ELEMENT
courtCircuit
(#PCDATA)
>

courtDepartment
is an optional element containing the name of the department of the court in
which the case is pending.

< !ELEMENT
courtDepartment
(#PCDATA)
>

venue
contains the content model for describing a location optionally using either
the name of the city or county and the state. The
<state/>
element is required. It describes the general location of the court.

< !ELEMENT
venue
((city | county)? , state)
>

agency
contains the elements and content model to describe the name of the agency in
which the proceeding is pending, its venue or more detailed contact
information, and information regarding the administrative officers involved in
the proceeding. This content model requires authors to provide the agency's
name (optionally followed by an office, bureau, department, or board name or
either an abbreviated name or agency acronym) or just an abbreviated name or
acronym of the agency. It also requires authors to provide either the venue of
the agency (city or county and state) or to provide more detailed contact
information (using the content model of the
%contact.content;
parameter entity previously described). Information about the administrative
officer(s) involved is optionally contained in the
<agency/>
element to reflect their relationship with the agency. The
<agency/>
element also has an optional
"agencyType"
element to describe the general category or level of the agency.

agencyName
is a required element containing the name of the agency in which the
proceeding is pending.

< !ELEMENT
agencyName
(#PCDATA)
>

agencyAcronym
is an optional element containing any common acronym by which the agency is
known.

< !ELEMENT
agencyAcronym
(#PCDATA)
>

agencyOffice
is an optional element containing the name of the office of the agency in
which the proceeding is pending.

< !ELEMENT
agencyOffice
(#PCDATA)
>

agencyBureau
is an optional element containing the name of the bureau of the agency in
which the proceeding is pending.

< !ELEMENT
agencyBureau
(#PCDATA)
>

agencyDepartment
is an optional element containing the name of the department of the agency in
which the proceeding is pending.

< !ELEMENT
agencyDepartment
(#PCDATA)
>

agencyBoard
is an optional element containing the name of the board of the agency in which
the proceeding is pending.

< !ELEMENT
agencyBoard
(#PCDATA)
>

fullCaseNumber
is an optional element containing the full case number of the case or
proceeding. It is incorporated from the Court Filing 1.1 DTD.

< !ELEMENT
fullCaseNumber
(#PCDATA)
>

caseTitle
is a required element containing the content model and elements for describing
the title of the case or administrative proceeding. It requires authors to
provide either 1) a full case title (e.g. Smith, et al. v. Jones, et al.); 2)
information regarding the group(s) of parties or individual parties (separated
by a
<vs/>
element as appropriate or, alternatively, information for an "In Re" (i.e. "In
the Matter of") case optionally followed by the name of the party involved
(e.g. In the Matter of D. R. Horton, Inc.); or 3) the title for an "in rem"
case or proceeding that does not involve people or organizations as parties
(e.g., In re Foreclosure of Lot #21, In the matter of Five 1999 Acura
Automobiles, etc.).

inRem
contains the title for an "in rem" case or proceeding that does not involve
people or organizations as parties.

< !ELEMENT
inRem
(#PCDATA)
>

partyGroup
contains one or more
<party/>
elements. Information about the attorney(s) for the party group also is
optionally contained within the
<partyGroup/>
element to reflect the attorney's relationship with the group. The
<partyGroup/>
element has a required
"partyType"
attribute to describe the particular type of party, e.g. "Paintiffs,"
"Respondents," "Third-Party Defendants," etc. It also has an optional
"id"
attribute.

vs
is an element used to separate the
<party/>
or
<partyGroup/>
elements.

< !ELEMENT
vs
(#PCDATA)
>

inRe
contains the text of an "In Re" (i.e. In the Matter of) case title (e.g. "In
the Matter of the Arbitration between Smith Construction Co. and Jones
Building, Inc."). If used, it must be followed by one or more
<party/>
elements.

< !ELEMENT
inRe
(#PCDATA)
>

relatedCase
is an optional element containing the content model and elements for
describing information about a related case or proceeding, such as one that has
been consolidated, transferred, or appealed. It uses the same content model and
elements in the
%caseMetadata;
parameter entity, except that the
<relatedCase/>
element is replaced by an optional
<comment/>
element.

The
<relatedCase/>
element has two attributes. The
"id"
attribute is optional. The
"relationshipType"
is a required enumerated attribute indicating whether the related case or
proceeding was consolidated, transferred, removed, appealed, or has some other
relationship with the pending case or proceeding.

2.4.6. Elements to Describe the Contents of the Body of an XML Court Document.

The Court Document 1.1 DTD organizes the text contents of the body of an XML
court document into a structural hierarchy of paragraph groups (i.e. sections),
paragraph subgroups (i.e. subsections), paragraphs, and subparagraphs.
Paragraph subgroups and subparagraphs extend to three levels, thus establishing
a hierarchical structure that includes sub-sub-subsections and
sub-sub-subparagraphs. The document body also contains a text-free
<machineData/>
element intended to hold data-containing elements specifically for use by
machines and it contains the date the XML court document was submitted for
filing.

Within paragraphs, the basic container of text content in the body of an XML
court document, the Court Document 1.1 DTD allows the use of various elements
to mark up footnotes, lists, citations, phrases, quotations, and similar items
of text content. Further, it permits the use of the "role" elements, such as
the
<person/>
or
<party/>
elements, within paragraphs.

The Court Document 1.1 DTD also allows the optional use of a special element
named
<addIn/>
within paragraphs. The
<addIn/>
element has an ANY content model, which means that it can contain parsed text
or any of the other elements declared in the Court Document 1.1 DTD. This makes
it a convenient mechanism for easily customizing and extending the DTD by
adding in new markup. New elements or parameter entities can be added to the
DTD and then used within an
<addIn/>
element in the paragraphs of an XML court document. The ANY content model can
be useful in the early stages of DTD development because it completely opens up
the element content models in the DTD. As a DTD matures, however, the use of
ANY can become a detriment, because new markup may be meaningless to
applications created to process existing XML documents. Since the effort to
develop a standard DTD for XML court documents is at an early stage, the
flexibility afforded by the ANY content model of the
<addIn/>
element is presumably more beneficial than detrimental.

documentBody
contains the elements and content models for marking up the text contents of
the body of a court document. It must contain one or more
<paragraphGroup/>
elements or one or more combinations of an optional
<paragraphTitle/>
element immediately followed by a
<paragraph/>
element. These elements are followed by a single required
<dateTimeSigned/>
element and an optional
<machineData/>
element.

paragraphGroup
contains the content model described in the
%paragraphGroup.model;
parameter entity. This element must contain either one or more paragraphs or
first-level subgroup(s) of paragraphs (i.e. a subsection). It also contains an
optional
<paragraphGroupTitle/>
element, which must precede any other elements if it is used.

The
<paragraphGroup/>
element has a required
"id"
attribute to hold a unique identifier. It also takes the optional content
attributes defined in the
%content.attributes;
parameter entity. The
"label"
attribute can contain a label, such as a number or letter designation, for the
paragraph group. The
"type"
attribute can describe the general category or nature of the paragraph group's
contents, and the
"subject"
attribute can contain comma-separated keywords or key phrases describing the
concepts discussed. The
"language"
attribute describes the language of the text using a two-letter ISO 639
language code. The
"privacy"
attribute indicates whether the paragraph group should be sealed or redacted.

paragraphGroupTitle
contains the title of a paragraph group or subgroup.

< !ELEMENT
paragraphGroupTitle
(#PCDATA)
>

paragraphSubgroup1
describes a first-level subgroup of paragraphs and must contain either one or
more paragraphs or second-level subgroup(s) of paragraphs (i.e. a
sub-subsection). It also contains an optional
<paragraphGroupTitle/>
element, which must precede any of the other elements. The
<paragraphSubgroup1/>
element takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
.

paragraphSubgroup2
must contain either one or more paragraphs or third-level subgroup(s) of
paragraphs (i.e. a sub-sub-subsection). It also contains an optional
<paragraphGroupTitle/>
element. The
<paragraphSubgroup2/>
element takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
.

paragraph
contains text expressing a thought, concept, or argument of an author. It has
a mixed content model (i.e. it can hold text and subelements). The subelements
that an author can optionally use to mark up information within a paragraph are
described primarily in the
%paragraph.content;
parameter entity. These optional subelements include any of the "role"
elements describing those involved in the case (e.g.
<party/>
,
<attorney/>
,
<person/>
, etc.), the
<addIn/>
element discussed previously, and a variety of elements describing particular
items of text content that frequently appear in the paragraphs of court
documents, such as footnotes, citations, phrases, quotations, lists, links,
dates, and addresses or venues. An
<annotation/>
element is provided to contain an author's notes. Additionally, a
<paragraphTitle/>
element and an element for first-level subparagraphs (
<subparagraph1/>
) also are provided.

subparagraph1
contains a first level subparagraph. It has a mixed content model (i.e. it can
hold text and subelements) like the
<paragraph/>
element. It contains the subelements described in the
%paragraph.content;
parameter entity along with a
<subparagraphTitle/>
element and second-level subparagraphs (
<subparagraph2/>
). The
<subparagraph1/>
element also takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
.

subparagraph2
contains a second level subparagraph (i.e. a sub-subparagraph). It has a mixed
content model (i.e. it can hold text and subelements) like the
<paragraph/>
element. It contains the subelements described in the
%paragraph.content;
parameter entity along with a
<subparagraphTitle/>
element and third-level subparagraphs (
<subparagraph3/>
). The
<subparagraph2/>
element also takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
.

subparagraph3
contains a third level subparagraph (i.e. a sub-sub-subparagraph). It has a
mixed content model (i.e. it can hold text and subelements) like the
<paragraph/>
element. It contains the subelements described in the
%paragraph.content;
parameter entity along with a
<subparagraphTitle/>
element. The
<subparagraph3/>
element also takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
.

addIn
is a special element having an ANY content model. It can contain parsed text
or any of the other elements declared in the Court Document 1.1 DTD. It is
provided as a convenient mechanism for easily customizing and extending the DTD
by adding in new markup. New elements or parameter entities can be added to the
DTD and then used within an
<addIn/>
element in the paragraphs of an XML court document. However, the
<addIn/>
element should be used with care, because new markup added by means of an
<addIn/>
element may be meaningless to applications created to process existing XML
court documents.

keyword
contains a single word or term having special significance or meaning. It
takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. It also has additional optional attributes that can be used to more
specifically define the particular meaning of the keyword. The
"description"
attribute contains a description or account of the content of the keyword. The
<keyword/>
element also has an optional
"id"
attribute.

literal
contains some specific piece of text or other data taken literally. It takes
the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. It also has a
"description"
attribute, which contains a description or account of the content of the
literal text or other data. The
<literal/>
element has an optional
"id"
attribute.

phrase
contains a short span of text having special significance or meaning. It takes
the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. It also has additional optional attributes that can be used to more
specifically define the particular meaning of the phrase. The
"description"
attribute contains a description or account of the content of the phrase. The
"source"
attribute refers to a resource from which the phrase is derived. The
<phrase/>
element also has an optional
"id"
attribute.

quotation
contains a quotation from another document or resource. It has mixed content
and can contain
<simpleCite/>
,
<keyword/>
,
<literal/>
,
<phrase/>
,
<date/>
, or
<link/>
elements as well as parsed text.

It takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. It also has a
"description"
attribute, which contains a description or account of the content of the
quotation. The
"source"
attribute refers to the resource from which the quotation is taken. The
<quotation/>
element has an optional
"id"
attribute.

footnote
contains a footnote. It must contain a
<footnoteNumber/>
element followed by a
<footnoteBody/>
element. It takes three of the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
, and
"subject"
. It also has a
"title"
attribute and an optional
"id"
attribute.

footnoteNumber
must contain the number of a footnote. It has no attributes.

< !ELEMENT
footnoteNumber
(#PCDATA)
>

footnoteBody
contains the body of a footnote. It has mixed content and can contain
<simpleCite/>
,
<keyword/>
,
<literal/>
,
<phrase/>
,
<quotation/>
,
<date/>
, or
<link/>
elements as well as parsed text. It has no attributes.

list
contains any sequence of items organized as a list. It must contain either one
or more
<listItem/>
element(s) or another
<list/>
element. It is the only element in the Court Document 1.1 DTD having a
recursive content model (i.e. a list can contain a list which can contain
another list, etc.). It takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. The
"type"
attribute may be used to describe whether the list is an ordered, unordered,
or other type of list. The
<list/>
element has an optional
"id"
attribute.

annotation
contains an annotation by an author or editor regarding the contents of a
paragraph. It has mixed content and can contain
<simpleCite/>
,
<keyword/>
,
<literal/>
,
<phrase/>
,
<quotation/>
,
<date/>
, or
<link/>
elements as well as parsed text.

It takes the optional content attributes defined in the
%content.attributes;
parameter entity --
"label"
,
"type"
,
"subject"
,
"language"
, or
"privacy"
. It also has several additional attributes. The optional
"id"
attribute identifies the annotation. The optional
"refersTo"
attribute contains the values of the
"id"
attributes of other elements to which it points. The
"creator"
attribute identifies the annotation author, and the
"description"
attribute describes the contents of the annotation.

dateTimeSigned
is a required element containing the date and time associated with the signing
of the court document for service or filing. It contains the
%dateTime.content;
parameter entity to incorporate the
<date/>
and
<time/>
elements and it has no attributes.

< !ELEMENT
dateTimeSigned
(% dateTime.content;)
>

machineData
contains one or more
<addIn/>
elements, but no text. The
<machineData/>
element is intended to serve as a container for marked up data-containing
elements needed by processing applications and from which such applications can
extract and use the data more easily and more reliably. Providing a container
element for this purpose avoids ambiguities that might arise from relying on
data elements within text-containing paragraphs because the surrounding textual
context might make the meaning of the marked up data element unclear. As
described previously, an
<addIn/>
element can contain any of the other elements declared in the Court Document
1.1 DTD and also is a mechanism for customizing and extending the DTD by adding
in new markup.

2.4.7. Elements to Describe the Signers of an XML Court Document.

The elements and content models for marking up information about the signers of
an XML court document are contained in the
<signers/>
element. These elements describe the text information that typically comprises
the signature block of a paper court document. However, the
<signers/>
element is not intended to serve as an electronic signature of an XML court
document. Electronic signature information is provided in the separate
<electronicSignature/>
element.

signers
contains the content model described in the
%signers.content;
parameter entity. It is an optional element, but if used it must contain
signatory information for one or more signers of the court document optionally
followed by a notarization. It has no attributes.

< !ELEMENT
signers
(%signers.content;)
>

signatory
contains the content model described in the
%signatory.content;
parameter entity. It requires authors either to mark up one or more signature
lines followed by information about one or more signatories, such as an
attorney, judicial officer, or enforcement officer, or to mark up information
about the signatory or signatories followed by one or more signature lines
depending on the sequence desired. It has no attributes.

< !ELEMENT
signatory
(%signatory.content;)
>

signatureLine
contains a signature line for the text of a signature. It has no attributes.

< !ELEMENT
signatureLine
(#PCDATA)
>

notarization
contains the content model described in the
%notarization.content;
parameter entity. It is an optional element, but if used it must contain
notarization information for one or more notaries. It has no attributes.
Notarizations typically appear in affidavits or verified court documents, such
as verified complaints.

< !ELEMENT
notarization
(signatureLine+, (%notarization.content;))
>

notaryDate
contains a text string giving the date of the notarization. It has a required
"date"
attribute to contain date information in ISO 8601 number format.

2.4.8. Elements to Describe a Certificate or Proof of Service.

The elements and content models for marking up information for a certificate or
proof of service of an XML court document are contained in the
<proofOfService/>
element. A certificate of service is required by the rules of legal procedure
in most U.S. courts. It documents that the party filing or serving a court
document has mailed or delivered (i.e. has served) a copy on the other parties.
The content model for a certificate or proof of service is described in the
%proofOfService.content;
parameter entity. It requires authors to provide one or more paragraphs,
followed by a required
<dateTimeServed/>
element indicating the date and, optionally the time, that the XML court
document was served (which may be different from the date the XML court
document itself was signed), and a required
<signatory/>
element to contain information about the signer of the certificate or proof of
service.

proofOfService
contains the content model described in the
%proofOfService.content;
parameter entity. It is an optional element, but if used it must contain one
or more paragraphs followed by the date (and optionally the time) of service,
and information about the signer of the certificate or proof of service. It has
no attributes.

< !ELEMENT
proofOfService
(%proofOfService.content;)
>

dateTimeServed
is a required element containing the date and optionally the time of the
serving of the court document. It contains the
%dateTime.content;
parameter entity to incorporate the
<date/>
and
<time/>
elements and it has no attributes.

< !ELEMENT
dateTimeServed
(% dateTime.content;)
>

2.4.9. Elements to Describe Attachments.

Electronic attachments to court documents present complications. Frequently
they will not be other XML documents. For example, an attachment to an XML
court document may be a binary word processing file or digital photo instead of
an XML court document. The Court
Document 1.1 DTD follows an approach similar
to the Court Filing 1.1 DTD, which assumes that attached items will be either
base-64 encoded BLOBs or, alternatively, a
<![CDATA[
(unparsed character data) section within the
<attachedItemContent/>
element or, when allowed by a court as a matter of local policy, a hyperlink.

attachedItem
describes the content model for an attachment to the XML court document. It
contains an optional
<documentMetadata/>
element, which contains elements for describing metadata about the attached
item, followed by one or more
<attachedItemContent/>
elements. This content model is different from the content model used to
describe attachments in the Court Filing 1.1 DTD and thus has a different
element name.

To accomodate the variety of items that might be
included as attachments, the Court Document 1.1 DTD follows an approach similar
to the Court Filing 1.1 DTD. It assumes that attached items will be either
base-64 encoded BLOBs or, alternatively, a
<![CDATA[
(unparsed character data) section within the
<attachedItemContent/>
element or a hyperlink (when allowed by a court as a matter of local policy).
Base-64 encoding removes the < and & characters and other XML
delimiters recognized as such by an XML parser. The alternative, marking a
section of text as CDATA, can be used for attachments that are XML documents
since it in effect turns off the parser so that the presence of XML elements
that are not declared in the XML Court Document 1.1 DTD will not trigger
parsing errors.

< !ELEMENT
attachedItem
(documentMetadata?, attachedItemContent)+
>

attachedItemContent
contains the contents of an attachment to the court document. The attachment
may be a base-64 encoded BLOB (particularly useful when the document being
filed is a binary file), or, alternatively, a
<![CDATA[
(unparsed character data) section. The
<attachedItemContent/>
element uses attributes borrowed from the Court Filing 1.1 DTD. It has a
required
"mimeType"
attribute to indicate how the contents of decoded PCDATA are to be interpreted
(e.g., application/PDF). The optional
"contentEncoding"
attribute indicates the type of content encoding used and allows for future
revisions. The
"href"
attribute specifies the location of a hyperlinked document.

2.4.10. Elements to Describe Electronic Signature Information.

The elements and content models used in the
<electronicSignature/>
element simply provide information by which applications can determine if,
how, and whether an XML court documents being read, exchanged or accessed has
been electronically signed, and if so, which electronic signature technologies
have been used.

electronicSignature
describes information by which an application can determine whether an XML
court document has been electronically signed, and if so, the particular
electronic signature technologies that have been used. The
<dataIntegrity/>
and
<authentication/>
elements are required, and the
<digitalSignatureInformation/>
element is optional.

authentication
contains information describing the means of authenticating an XML court
document. The optional
"userIdentification"
and
"password"
attributes provide for authentication by means of a user id and password. The
<authentication/>
element has a required
"autheticationType"
enumerated attribute to indicate the type of authentication used.

digitalSignatureInformation
has an ANY content model and is a placeholder for information regarding digital
signatures. It is anticipated that the content model for this element will
ultimately incorporate or mirror standard elements and attributes for XML
digital signatures.

< !ELEMENT
digitalSignatureInformation
ANY
>

3. Future Developments.

Work to develop standards for XML court documents is ongoing. This Court
Document 1.1 proposed standard is based upon a Document Type Definition
(DTD), but DTD's are currently being replaced by W3C XML schemas. XML schemas
are a more robust way of defining XML elements and content models that avoid
some of the limitations and
difficulties of DTDs. Thus, it is anticipated that future efforts to establish
a standard for XML court documents will include a proposed XML schema as well
as refinements and updates to the Court Document DTD.

Appendix A - General Entities

The general entities declared in the Court Document 1.1 DTD are derived from
the corresponding ISO 8879 standard entity set as incorporated in the
Simplified DocBook DTD v4.1.2.5. The general entities permit various
characters such as the section, paragraph, currency, fractions, and other
symbols and signs to be used within XML court documents. For instance,
"& para;" (without whitespace) can be used in an XML court document for the
paragraph symbol and "& sect;" (also without whitespace) can be used for
the section symbol. The character entities are declared at the beginning of the
DTD and then can be used at any point within an XML court document.

The general character entities in the Court Document 1.1 DTD are listed
here.

Appendix B - Element List

The elements declared in the Court Document 1.1 DTD are listed alphabetically
in a
Court Document 1.1 Element List
. The table lists the Court Document 1.1 elements by name, briefly describes
them,
states the other elements that use them and the other elements they
contain, and, where applicable, identifies the corresponding Court Filing
1.1 element.

Appendix C - Sample XML Court Documents

The sample XML court documents in this Appendix are for purposes of
illustration only. The sample stylesheets also are solely for purposes of
illustrating how stylesheets can be used to display the contents of XML court
documents. As noted in the proposed Court Document 1.1 standard, if an
inconsistency arises between an example document and the Court Document 1.1
DTD, the DTD shall control. The Court Document 1.1 standard also does not
attempt to establish any standard stylesheets for displaying XML court
documents -- the samples in this Appendix simply illustrate one way that the
contents of XML documents can be transformed for display to human readers using
a stylesheet. It is conceivable that courts may develop standard stylesheets
for displaying XML court documents uniformly and the creation of more tailored
and more fully developed stylesheets is expected..

The sample XML court documents all are valid against the proposed Court
Document 1.1 DTD. They include a variety of representative documents from both
courts and agencies. To view the court document as raw XML, use the "View
Source" feature of the web browser.

National Labor Relations Board Decision
containing as separate attachments an XSL stylesheet for transforming XML
content to
XSL:FO (Extensible Stylesheet Language: Formatting Objects)
and the XSL:FO output file resulting from the transformation. In contrast to
XSLT stylesheets, which transform XML content into various output files such as
HTML suitable for display to readers, XSL:FO stylesheets specify the page
format, page size, page numbering, font size, font style, indentation, and
other properties useful for printing (as well as displaying) XML content or for
converting XML content into printer friendly formats, such as PDF files. The
XSL:FO output in this sample can be converted to a PDF file using applications
such as XSL Formatter from
Antenna House
; FOP, the Formatting Objects Processor, from
The Apache XML Project
; or similar applications.