Legal XML Proposed Standard: XML Standards Development Project -- XML Court Document 1.1 Draft Standard

Copyright 2002 Legal XML, Inc. All Rights Reserved. Legal XML, Inc. Operating Rules apply.

Current Version: 1.1

2002-05-31

Short Statement of Status: Active

Workgroup Information

Workgroup Name: Court Filing
Workgroup Mailing List: http://lists.oasis-open.org/archives/legalxml-courtfiling-discuss/
Workgroup Website: http://oasis-open.org/committees/legalxml-courtfiling/
Workgroup Chair(s): John Greacen (john@greacen.net)

Document Author(s)

Mohyeddin Abdulaziz (abdulaziz@law.arizona.edu)
Rolly Chambers (rlchambers@smithcurrie.com)
John Messing (jmessing@law-on-line.com)

Document Editor(s)

Mohyeddin Abdulaziz (abdulaziz@law.arizona.edu)
Rolly Chambers (rlchambers@smithcurrie.com)
John Messing (jmessing@law-on-line.com)

Previous Version(s): Court Document 1.0 (2001-06-21)

Abstract

This Draft Standard provides the draft Legal XML Court Document 1.1 DTD. 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. It substantially modifies the previously proposed draft Court Document 1.0 DTD (2001-06-21).


Table of Contents

Status of Document
1. Introduction
1.1. Conventions
1.2. Description
1.3. Assumptions and Requirements
1.3.1. Assumptions about Authoring and Displaying XML Documents
1.3.2. Assumptions about Court Documents
1.3.3. Relationship of the Court Document 1.1 Standard with the Legal XML Court Filing 1.1 Standard
1.3.4. Relationship of the Court Document 1.1 DTD with Other XML DTDs
1.3.5. XML Namespaces and the XML Court Document 1.1 DTD
1.3.6. Customizing the Court Document 1.1 DTD
1.3.7. Specific Assumptions and Requirements
2. DTD Specification
2.1. DTD Specification
2.2. Character Entities
2.3. Parameter Entities
2.4. Elements and Attributes.
2.4.1. Common Elements to Describe Names, Contact, Role, Date and Time, and XML Linking Information
2.4.2. Elements to Describe Information about Those Involved in a Court or Administrative Proceeding
2.4.3. Elements to Describe the Basic Parts of an XML Court Document
2.4.4. Elements to Describe Document Metadata
2.4.5. Elements to Describe Case Metadata
2.4.6. Elements to Describe the Contents of the Body of an XML Court Document
2.4.7. Elements to Describe the Signers of an XML Court Document
2.4.8. Elements to Describe a Certificate or Proof of Service
2.4.9. Elements to Describe Attachments
2.4.10. Elements to Describe Electronic Signature Information
3. Future Developments.
A. Appendix A - General Entities
B. Appendix B - Court Document 1.1 Element List
C. Appendix C - Sample XML Court Documents

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 conforms to the XML 1.0 Specification (2nd ed. October, 2001) ( http://www.w3.org/TR/REC-xml.html ).

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.

1.3.3 Relationship of the Court Document 1.1 Standard with the Legal XML Court Filing 1.1 Standard

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:

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:

  1. The Court Document 1.1 XML standard should be relatively easy to learn and use, but sufficiently comprehensive to allow application developers to produce applications allowing easy, intuitive document authoring and useful processing of XML court documents, including:
    • 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.
  2. 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.
  3. 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

Date DTD
2002-05-31 courtdocument11.dtd
2002-05-31 scourtdocument11.dtd

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.

2.3.2.    % paragraphGroup.model Parameter Entity

< !ENTITY % paragraphGroup.model ; "paragraphGroupTitle? , (paragraphSubgroup1 | (%paragraph.model;))+" >

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.

2.3.4.    % personName Parameter Entity

< !ENTITY % personName.content "((fullName , aliasName*) | aliasName | (namePrefix? , firstName? , nickName? , middleName* , lastName , nameSuffix? , aliasName*))" >

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.

2.3.5.    % organizationName Parameter Entity

< !ENTITY % organizationName.content "((organizationName , organizationUnit* , (aliasName* , organizationAcronym? , abbreviatedName?)?) | abbreviatedName | organizationAcronym | aliasName)" >

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.

2.3.7.    % contact.content Parameter Entity

< !ENTITY % contact.content "postalAddress* , (fullTelephone | telephone)* , (fullFax | fax)* , email* , uri*" >

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.

2.3.8.    % personIdentification.content Parameter Entity

< !ENTITY % personIdentification.content "personalIDNumber* , (birthDate | age)? , comment*" >

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.

2.3.9.    % organizationIdentification.content Parameter Entity

< !ENTITY % organizationIdentification.content "organizationIDNumber* , comment*" >

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.

2.3.10.    % postalAddress.content Parameter Entity

< !ENTITY % postalAddress.content "(addressLine* , city? , county? , state? , postalCode? , country?) | fullAddress" >

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.

2.3.11.    % documentMetadata.content Parameter Entity

< !ENTITY % documentMetadata.content "documentIdentifier? , dateTimeCreated , documentTitle? , documentStatus? , documentType , creator , contributor* , submitter , description? , subject? , reference* , format , language? , coverage?" >

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.

2.3.13.    % caseMetadata.content Parameter Entity

< !ENTITY % caseMetadata.content "(%tribunal.content;) , fullCaseNumber? , caseTitle? , documentTitle , relatedCase*" >

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.

2.3.14.    % paragraph.content Parameter Entity

< !ENTITY % paragraph.content "addIn | simpleCite | keyword | literal | phrase | quotation | footnote | list | annotation | link | image | date | venue | postalAddress | person | witness | victim | organization | partyGroup | party | attorney | judicialOfficer | administrativeOfficer | enforcementOfficer | court | agency" >

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.

2.3.16.    % signatory.content Parameter Entity

< !ENTITY % signatory.content "(signatureLine+ , (attorney | party | judicialOfficer | administrativeOfficer | enforcementOfficer | witness | court | agency)+) | ((attorney | party | judicialOfficer | administrativeOfficer | enforcementOfficer | witness | court | agency)+ , signatureLine+)" >

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.

2.3.17.    % notarization.content Parameter Entity

< !ENTITY % notarization.content "notary , notaryDate , notarySeal , notaryExpiration" >

Parameter entity for the content model for a notarization. This content model allows authors to mark up notarizations in affidavits, verifications, and similar court documents.

2.3.18.    % proofOfService.content Parameter Entity

< !ENTITY % proofOfService.content "(%paragraph.model;)+ , dateTimeServed , signatory" >

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.

2.3.19.    % content.attributes Parameter Entity

< !ENTITY % content.attributes
" label CDATA #IMPLIED
type CDATA #IMPLIED
subject CDATA #IMPLIED
language CDATA #IMPLIED
privacy (sealed | redacted ) #IMPLIED " >

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.

2.3.20.    % common.attributes Parameter Entity

< !ENTITY % common.attributes
" id ID #IMPLIED
type CDATA #IMPLIED
codeLiteral CDATA #IMPLIED
codeSource CDATA #IMPLIED
codeValue CDATA #IMPLIED
referenceDate CDATA #IMPLIED
status CDATA #IMPLIED " >

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.

2.3.21.    % xlink.attributes Parameter Entity

< !ENTITY % xlink.attributes
" xmlns:xlink CDATA #FIXED
'http://www.w3.org/1999/xlink'
xlink:type (simple|extended|locator|arc|resource) 'simple'
xlink:href CDATA #REQUIRED
xlink:role CDATA #IMPLIED
xlink:title CDATA #IMPLIED
xlink:show (new|replace|embed|other|none) 'replace'
xlink:actuate (onLoad|onRequest|other|none) 'onRequest'
" >

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.

2.3.22.    % state.codes Parameter Entity

< !ENTITY % state.codes "AK |AL | AZ | AR | CA | CO | CT | DC | DE | DL | FL | GA | HI | ID | IL | IN | IA | KS | KY | MA | MD | ME | MI | MN | MO | MT | NC | ND | NE | NH | NJ | NM | NV | NY | OH | OK | OR | PA | PR | RI | SC | TN | TX | UT | VA | VT | WA | WI | WV | WY" >

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.

    < !ELEMENT fullName (#PCDATA) >
    < !ATTLIST fullName %common.attributes; >
  • 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.

    < !ELEMENT aliasName (#PCDATA) >
    < !ATTLIST aliasName aliasFor IDREF #IMPLIED
    aliasType (dba | aka | fka | nka | nee ) #REQUIRED >
  • 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.

    < !ELEMENT namePrefix (#PCDATA) >
    < !ATTLIST namePrefix %common.attributes; >
  • 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.

    < !ELEMENT firstName (#PCDATA) >
    < !ATTLIST firstName %common.attributes; >
  • 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.

    < !ELEMENT middleName (#PCDATA) >
    < !ATTLIST middleName %common.attributes; >
  • 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.

    < !ELEMENT lastName (#PCDATA) >
    < !ATTLIST lastName %common.attributes; >
  • 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.

    < !ELEMENT nameSuffix (#PCDATA) >
    < !ATTLIST nameSuffix %common.attributes; >
  • organizationName contains an organization's full name. It is based on the <entityName/> element in the Court Filing 1.1 DTD.

    < !ELEMENT organizationName (#PCDATA) >
    < !ATTLIST organizationName %common.attributes; >
  • organizationUnit contains the name of a division or department within an organization. It is not included in the Court Filing 1.1 DTD.

    < !ELEMENT organizationUnit (#PCDATA) >
    < !ATTLIST organizationUnit %common.attributes; >
  • abbreviatedName contains the abbreviated name of an organization (or court or agency). It is based on the <entityAbbreviatedName/> element in the Court Filing 1.1 DTD.

    < !ELEMENT abbreviatedName (#PCDATA) >
    < !ATTLIST abbreviatedName %common.attributes; >
  • organizationAcronym contains any common acronym by which an organization is known. It is based on the <entityAcronym/> element in the Court Filing 1.1 DTD.

    < !ELEMENT organizationAcronym (#PCDATA) >
    < !ATTLIST organizationAcronym %common.attributes; >
  • 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.

    < !ELEMENT postalAddress (%postalAddress.content;) >
    < !ATTLIST postalAddress %common.attributes;
    addressType (work | home | unknown ) 'work' >
  • 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.

    < !ELEMENT addressLine (#PCDATA) >
    < !ATTLIST addressLine %common.attributes; >
  • 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.

    < !ELEMENT state (#PCDATA) >
    < !ATTLIST state stateCode (%state.codes;) #IMPLIED
    %common.attributes; >
  • postalCode contains the zip or postal code. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT postalCode (#PCDATA) >
    < !ATTLIST postalCode %common.attributes; >
  • country contains the name of the country. It is incorporated from the Court Filing 1.1 DTD. The ISO 3166 abbreviations for country names must be used if the country name is abbreviated.

    < !ELEMENT country (#PCDATA) >
    < !ATTLIST country %common.attributes; >
  • 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.

    < !ELEMENT fullAddress (#PCDATA) >
    < !ATTLIST fullAddress %common.attributes; >
  • telephone contains the information for a telephone number. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT telephone (telephonePrefix? , telephoneNumber , telephoneSuffix?) >
    < !ATTLIST telephone %common.attributes; >
  • telephonePrefix contains the prefix information related to a telephone number, e.g., a country and city code, or an area code. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT telephonePrefix ((telephoneCountryCode? , telephoneCityCode?) | areaCode?) >
    < !ATTLIST telephonePrefix %common.attributes; >
  • telephoneCountryCode contains the country code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT telephoneCountryCode (#PCDATA) >
    < !ATTLIST telephoneCountryCode %common.attributes; >
  • telephoneCityCode contains the city code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT telephoneCityCode (#PCDATA) >
    < !ATTLIST telephoneCityCode %common.attributes; >
  • areaCode contains the area code for a telephone number. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT areaCode (#PCDATA) >
    < !ATTLIST areaCode %common.attributes; >
  • 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.

    < !ELEMENT telephoneNumber (#PCDATA) >
    < !ATTLIST telephoneNumber %common.attributes;
    format CDATA #IMPLIED >
  • telephoneSuffix contains the suffix, such as an extension, for a telephone number. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT telephoneSuffix (#PCDATA) >
    < !ATTLIST telephoneSuffix %common.attributes; >
  • 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.

    < !ELEMENT fullTelephone (#PCDATA) >
    < !ATTLIST fullTelephone telephoneType (work | home | mobile | pager | unknown ) 'work' >
  • 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.

    < !ELEMENT fullFax (#PCDATA) >
    < !ATTLIST fullFax faxType (work | home | unknown ) 'work' >
  • 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.

    < !ELEMENT email (#PCDATA) >
    < !ATTLIST email %common.attributes;
    emailType (work | home | mobile | unknown ) 'work' >
  • 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.

    < !ELEMENT roleWith (#PCDATA) >
    < !ATTLIST roleWith actorID IDREF #IMPLIED >
  • 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.

    < !ELEMENT date (#PCDATA) >
    < !ATTLIST date %common.attributes;
    date CDATA #REQUIRED
    dateType CDATA #IMPLIED >
  • 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.

    < !ELEMENT time (#PCDATA) >
    < !ATTLIST time %common.attributes;
    time CDATA #REQUIRED >
  • 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.

    < !ELEMENT image EMPTY >
    < !ATTLIST image xmlns:xlink CDATA #FIXED "http://www.w3.org/1999/xlink"
    xlink:type CDATA #FIXED "simple"
    xlink:href CDATA #REQUIRED
    xlink:title CDATA #IMPLIED
    xlink:show CDATA #FIXED "onLoad"
    xlink:actuate CDATA #FIXED "embed" >

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.

    < !ELEMENT person (%personName.content; , %contact.content; , personIdentification? , (%role.content;)?) >
    < !ATTLIST person id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT personalIDNumber (#PCDATA) >
    < !ATTLIST personalIDNumber issuingAuthority CDATA #IMPLIED
    %common.attributes; >
  • 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.

    < !ELEMENT birthDate (#PCDATA) >
    < !ATTLIST birthDate date CDATA #REQUIRED
    %common.attributes; >
  • age contains the age of a person. It is not included in the Court Filing 1.1 DTD.

    < !ELEMENT age (#PCDATA) >
  • comment contains the text of a comment. It is incorporated from the Court Filing 1.1 DTD.

    < !ELEMENT comment (#PCDATA) >
    < !ATTLIST comment %common.attributes; >
  • 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.

    < !ELEMENT attorney (%personName.content; , %contact.content; , barNumber? , personIdentification? , (%role.content;)?) >
    < !ATTLIST attorney id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT barNumber (#PCDATA) >
    < !ATTLIST barNumber issuingAuthority CDATA #IMPLIED
    yearAdmitted CDATA #IMPLIED
    barStatus CDATA #IMPLIED >
  • 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.

    < !ELEMENT judicialOfficer (%personName.content; , %contact.content; , personIdentification? , (%role.content;)?) >
    < !ATTLIST judicialOfficer id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT notary (%personName.content; , %contact.content; , personIdentification? , (%role.content;)?) >
    < !ATTLIST notary id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT administrativeOfficer (%personName.content; , %contact.content; , personIdentification? , (%role.content;)?) >
    < !ATTLIST administrativeOfficer id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT enforcementOfficer (%personName.content; , %contact.content; , personIdentification? , (%role.content;)?) >
    < !ATTLIST enforcementOfficer id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT witness (%personName.content; , %contact.content; , personIdentification? , %role.content;) >
    < !ATTLIST witness id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT organization (%organizationName.content; , %contact.content; , organizationIdentification? , (%role.content;)?) >
    < !ATTLIST organization id ID #IMPLIED
    reference IDREF #IMPLIED
    privacy (sealed | redacted ) #IMPLIED >
  • 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.

    < !ELEMENT organizationIdentification (%organizationIdentification.content;) >
  • 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.

    < !ELEMENT organizationIDNumber (#PCDATA) >
    < !ATTLIST organizationIDNumber issuingAuthority CDATA #IMPLIED
    %common.attributes; >
  • 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.

    < !ELEMENT victim (person | organization) >
    < !ATTLIST victim id ID #IMPLIED >
  • 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.

    < !ELEMENT party ((person | organization) , attorney*) >
    < !ATTLIST party partyType partyType #REQUIRED
    id ID #IMPLIED >

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.

    < !ELEMENT courtDocument (documentMetadata , caseMetadata , documentBody , signers? , proofOfService? , attachedItem*, electronicSignature?) >
    < !ATTLIST courtDocument version CDATA #FIXED '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.

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.

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.

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.

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.

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.

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.

    < !ELEMENT electronicSignature (dataIntegrity , authentication , digitalSignatureInformation?)+ >
  • dataIntegrity identifies the type of binding used for purposes of data integrity. It has a required "bindingType" enumerated attribute from which the specific type of bindng can be selected.

    < !ELEMENT dataIntegrity (#PCDATA) >
    < !ATTLIST dataIntegrity bindingType (none | hash | authenticationCode | digitalSignature | symmetricKey | other ) #REQUIRED >
  • 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.

    < !ELEMENT authentication (#PCDATA) >
    < !ATTLIST authentication userIdentification CDATA #IMPLIED
    password CDATA #IMPLIED
    authenticationType (none | passwordPlain | passwordCrypto | X-509 | biometric | signatureDynamics | signatureImage | other) #REQUIRED >
  • 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 documents can be viewed in XSLT capabale web browsers on client machines. The Microsoft Internet Explorer 5.0 web browser or higher (assuming that the msxml3 or msxml4 XML parser and XSLT processor is installed) and the Mozilla 1.0 Release Candidate 3 web browser can display XML documents using XSLT stylesheets.

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.