OASIS LegalXML Member Section XML Court Document 1.1 Candidate Specification

OASIS Committee Draft and Legal XML Court Filing Work Group Candidate Specification 01, 2002-10-01

Document identifier:

cd-courtfiling-courtDocument11-01

Location:

http://www.oasis-open.org/committees/legalxml-courtfiling/

Editor:

Roger Winters, Washington State Courts and King County Judicial Administration < roger.winters@metrokc.gov >

Authors:

Mohyeddin Abdulaziz, Arizona Court of Appeals < abdulaziz@law.arizona.edu >
Rolly Chambers, Smith, Currie & Hancock LLP < rlchambers@smithcurrie.com >
John Messing, Law-on-Line < jmessing@law-on-line.com >

Abstract:

This Committee Draft, the XML Court Document 1.1 Candidate Specification, provides the proposed Legal XML Court Document 1.1 DTD. The Court Document 1.1 DTD sets forth standard XML elements, attributes, and content models for using XML to "mark up" court documents from a wide range of jurisdictions. It modifies the previous draft of the Court Document 1.1 DTD (dated 2002-05-31).

Status:

This is a Candidate Specification of the OASIS Legal XML Electronic Court Filing TC for review and discussion by interested TC members.

If you are on the < legalxml-courtfiling-document@lists.oasis-open.org > list for committee members, send all comments there. If you are not on that list, subscribe to the < legalxml-courtfiling-comment@lists.oasis-open.org > list and send all comments there. To subscribe, send an email message to < legalxml-courtfiling-comment-request@lists.oasis-open.org > with the word " subscribe " as the body of the message.

Copyright © 2002 The Organization for the Advancement of Structured Information Standards [OASIS]

Table of Contents

1. Introduction
2. Description
3. Terminology
4. Conventions
5. Assumptions and Requirements
5.1. Assumptions about Authoring and Displaying XML Documents
5.2. Assumptions about Court Documents
5.3. Relationship of the Court Document 1.1 Candidate Specification to the Legal XML Electronic Court Filing 1.1 Proposed Specification
5.4. Relationship of the Court Document 1.1 DTD with Other XML Specifications
5.5. XML Namespaces and the XML Court Document 1.1 DTD
5.6. Extending and Customizing the Court Document 1.1 DTD
5.7. Assumptions and Requirements
6. DTD Specification
6.1. Court Document 1.1 DTD
6.2. Character Entities
6.3. Parameter Entities
6.3.1. % person.ANY Parameter Entity
6.3.2. % organization.ANY Parameter Entity
6.3.3. % paragraph.ANY Parameter Entity
6.3.4. % XML Digital Signature Parameter Entities
6.3.5. % paragraph.model Parameter Entity
6.3.6. % paragraphGroup.model Parameter Entity
6.3.7. % dateTime.content Parameter Entity
6.3.8. % personName.content Parameter Entity
6.3.9. % personIdentification.content Parameter Entity
6.3.10. % organizationName.content Parameter Entity
6.3.11. % organizationIdentification.content Parameter Entity
6.3.12. % contact.content Parameter Entity
6.3.13. % postalAddress.content Parameter Entity
6.3.14. % documentMetadata.content Parameter Entity
6.3.15. % caseMetadata.content Parameter Entity
6.3.16. % paragraph.core Parameter Entity
6.3.17. % signatory.content Parameter Entity
6.3.18. % notarization.content Parameter Entity
6.3.19. % content.attributes Parameter Entity
6.3.20. % common.attributes Parameter Entity
6.3.21. % xlink.attributes Parameter Entity
6.3.22. % state.codes Parameter Entity
6.4. Elements and Attributes
6.4.1. Elements to Describe the Basic Components of a Legal XML Court Document
6.4.2. Elements to Describe Document Metadata
6.4.3. Elements to Describe Information about Those Involved in a Court or Administrative Proceeding
6.4.4. Common Elements to Describe Names, Contact, Role, Date and Time, and XML Linking Information
6.4.5. Elements to Describe Case Metadata
6.4.6. Elements to Describe the Contents of the Body of a Legal XML Court Document
6.4.7. Elements to Describe the Signer(s) of a Legal XML Court Document
6.4.8. Elements to Describe a Certificate or Proof of Service
6.4.9. Elements to Describe Attachments to a Legal XML Court Document
6.4.10. Elements to Describe Electronic Signature Information
7. Future Developments

Appendixes

A. General Entities
B. Court Document 1.1 Element List
C. Sample XML Court Documents
D. Notices
References

1. Introduction

This document is intended to provide information required for indicating the structure and semantic meaning of the contents of electronic court documents using XML.

This document is an OASIS Committee Draft (a Legal XML Member Section "Candidate Specification") according to the specification processing terms of the Legal XML Electronic Court Filing TC collaboratively developed by the Council of State Court Administrators/National Association for Court Management (COSCA/NACM) Joint Technology Committee (the JTC) and the OASIS Legal XML Electronic Court Filing TC.

This Candidate Specification, the 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 Electronic Court Filing 1.1 Proposed Standard (2002-07-22) . This Candidate Specification is a work in progress and further development of the specification is expected and welcomed.

2. Description

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

Examples provided in the appendices are non-normative, that is, they are provided only for illustration. Although they contain well formed, valid examples of XML based Court Documents, for any inconsistency that might arise between an example and the Court Document 1.1 DTD, the DTD shall be treated as correct.

3. Terminology

The key words must , must not , required , shall , shall not , should , should not , recommended , may , and optional in this document are to be interpreted as described in [ RFC 2119 ].

The term author means the person creating or editing an XML court document.

The term court document means the category of legal documents filed with courts or administrative agencies or documents exchanged by the parties in discovery in formal legal proceedings, such as civil or criminal lawsuits or administrative hearings. Court documents include pleadings, orders, briefs, motions, notices, and similar items pertaining to court proceedings.

The key words filing , electronic filing , filing data , and filing metadata have the meanings described in the Legal XML Court Filing 1.1 Proposed Standard (2002-07-22) .

The terms processing application and application mean applications whose function includes processing XML marked-up court documents.

4. Conventions

The proposed DTD described in this Candidate Specification conforms to the XML 1.0 Specification (2nd ed. October, 2000) .

This Candidate Specification also adheres to the conventions followed in the Legal XML Electronic Court Filing 1.1 Proposed Standard (2002-07-22) with respect to element and attribute naming and the capitalization of XML tags.

5. Assumptions and Requirements

5.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 create the text and also must choose and indicate the appropriate XML markup to describe that text. XML authoring applications can simplify the process with menus, forms, buttons, and other ways for authors to choose the appropriate tags to mark up the text in an XML document, but it takes more physical and mental effort (and extra time) to create a document containing XML markup than to create a comparable text document from scratch in a word processor. Facilitating the ease of creating XML court documents was a primary consideration in the drafting of the Court Document 1.1 DTD.

The Court Document 1.1 DTD seeks relative simplicity, consistency, and flexibility in its XML content models, as opposed to including comprehensive detail and rigid structures. The Court Document 1.1 DTD assumes that most of the information needed to create XML-tagged court documents will come from human authors, that is, from lawyers, judges, clerks, paralegals, and legal secretaries, rather than from non-human sources like databases. This specification anticipates that human authors, rather than machines, will choose the XML markup tags that describe the structure and semantic meaning of the information in XML-tagged court documents.

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 the contents of such documents are not likely to be readily reusable in other contexts or cases. This specification also assumes that the basic structures of ordinary grammar, the phrase and paragraph, as opposed to a comprehensive set of data elements, are the preferred containers for text expressing legal ideas and concepts in XML-tagged court documents. The specification 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 fundamental characteristic of XML markup is that it explicitly distinguishes the use of markup to describe the logical structure and semantic content of a document from information describing the way the structured document would be displayed to a reader. This separation of content from display is often troublesome for 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 a structure on a document by changing the appearance of the text. They might underline or italicize words for emphasis or use different fonts or indentations (that is, introduce white space) for headings, titles, or to designate subparts of a section or paragraph. The display format an author uses gives the document a 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 like XML use named elements, not visual font changes, indentations, and the like, to indicate the structure and semantic meaning of the text in a document. The markup tags (rather than stylistic formatting) impart structure to the document. For example, the XML element <documentTitle/> indicates the text it contains is the title assigned to the document, but it says nothing about the font or spacing that should be used to display that text. Structured markup, however, makes it possible for software to interpret and process documents for many different purposes. 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, including HTML on a Web page, printouts to paper, Braille, or even audio, all of them using the very same source document.

Because XML documents separate content from display, a separate tool called a "stylesheet" is typically used to display the structured form. Information regarding the fonts, margins, indentation and other aspects of displaying the structured document is contained in the stylesheet, but not in the structured document itself. 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. A stylesheet can contain information regarding the font style, font size, and indentations to be used for displaying the contents of a <documentTitle/> element.

This specification assumes that stylesheets usually will be used to display the contents of XML court documents to readers. The samples in the appendices include sample stylesheets for purposes of illustration only. The Court Document 1.1 specification does not attempt to establish standard stylesheets for displaying the contents of XML court documents. It assumes that XML elements describing the structure and contents of court documents should permit such documents to be displayed by stylesheets in a form substantially similar to the familiar display of paper court documents. It is assumed that a court or agency may develop standard stylesheet(s) to display the contents of XML court documents setting the margins, fonts, indentation, and so forth, in the particular way preferred. This specification also assumes that an author might include a stylesheet with an XML court document if there were a need or desire to include display information. A receiving application would then need to extract the stylesheet and apply it to the XML document to display the document as the stylesheet requires.

5.2. Assumptions about Court Documents

The term "court documents" means 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 include pleadings, orders, briefs, motions, and similar items pertaining to formal legal proceedings. They also include documents related to a case that may never actually be filed in a court, such as discovery documents, disclosure statements, and offers of judgment. This specification assumes that court documents possess certain common features relative to their basic organization and structure. It also assumes that the basic organization and structure of information in court documents, and the semantic meaning of such information, can be described using XML elements and attributes.

The Court Document 1.1 DTD proposes standard XML elements, attributes, and content models for marking up court documents used in a wide range of jurisdictions. Its content models are generic in nature, derived primarily from the information and structures observed in paper court documents. In this regard, the Court Document 1.1 DTD is "document-centric," dealing more with the structure and content of the document itself, but not "data-centric," focusing less on defining standard data elements that might be contained in them. Through the use of attributes, the Court Document 1.1 DTD provides for semantic descriptions of text contained in structural elements, but it does not define all the specific data elements that might be found in court documents.

Court documents share a general structure. They also typically contain technical legal terms and concepts and hold many kinds of data interspersed throughout the body of the document, in its phrases, quotations, citations, lists, and otherwise. These technical legal terms, concepts, and other data -- for example, names, addresses, and dates -- could be described and categorized in many different ways. It is possible to define standard XML mark up tags to describe specific technical legal terms such as "hearing," "verdict," "juror," "judgment," "fine," "creditor," "writOfMandamus," and so forth. There are a vast number of special terms that make up different specialized legal vocabularies relating to the different areas of legal practice for which court documents might be created.

Criminal, domestic, immigration, real estate, tax, family law, and similarly "specialized" areas of legal practice use hundreds of special terms to communicate precisely the substantive and procedural legal concepts that have technical meanings within those practice 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 and would result in a large and complicated DTD. A large and complicated set of XML elements is likely to be more difficult to learn and use. Completing extensive legal data dictionaries that would be needed to encompass all of the concepts and terms used in all of the many aspects of the practice of law might take years. Thus, the Court Document 1.1 DTD does not attempt to define XML markup for "data sets" of special legal terms and concepts that might appear in a court document used for a specific area of legal practice. It is anticipated that the comprehensive legal data dictionaries for describing all the legal terms and concepts that appear in court documents will emerge over time.

The Court Document 1.1 DTD marks a beginning by describing the organization and structure of the information contained in court documents. It includes some general XML tags for marking up phrases, quotations, lists, and similar structural items that often appear in the body of court documents. Through the use of attributes, it also allows for semantically meaningful descriptions of such structural elements. This specification assumes, however, that more specialized standard XML vocabularies used in particular areas of legal practice will have to be developed over time and that a means should be provided to allow authors to mark up specialized legal terms within XML court documents. The specification provides a basic framework and general starting point from which further development can proceed. For example, a standard XML or other schema for validating XML court documents presumably will be developed in addition to or as a replacement for the Court Document 1.1 DTD.

5.3. Relationship of the Court Document 1.1 Candidate Specification to the Legal XML Electronic Court Filing 1.1 Proposed Specification

The Court Document 1.1 DTD and the Legal XML Electronic Court Filing 1.1 DTD serve different though related purposes. The Court Filing 1.1 specification 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 those data elements, their attributes, and their relationships. It uses XML to promote data interchange with court filing management systems. However, it does not include information about the detailed content or structure of the pleading or other court document contained within the standardized XML envelope.

The Court Document 1.1 DTD in contrast defines XML elements and attributes used 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 textual analysis of court documents, and perhaps for other purposes, including the automated generation and processing of some court documents. 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 except by means of applications implementing the Court Filing 1.1 specification.

This specification assumes that XML court documents, when included within XML electronic filings conforming to the Court Filing 1.1 specification, 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 would 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 electronic filing to avoid validation errors. Base-64 encoding removes the < and & characters and other XML delimiters recognized as such by the XML parser.

Alternatively, it also is possible to include an XML document, XML tags and all, within a <![CDATA[ (unparsed character data) section in 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 document envelopes 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 any further processing.

The Court Document 1.1 DTD also favors consistency with the Court Filing 1.1 XML specification 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 specification have been included in the Court Document 1.1 DTD. A few have been modified to promote the goals of simplicity, consistency, and flexibility. Such modifications and the rationale for them are noted where they occur. When discrepancies between element content models in this specification and the Court Filing 1.1 element content models exist, this specification applies only with respect to XML court documents. Applications for processing court documents and court filing envelopes will accordingly have to process different data elements depending on whether they are located in a court filing envelope or in a court document.

5.4. Relationship of the Court Document 1.1 DTD with Other XML Specifications

The Court Document 1.1 DTD employs some of the techniques used in other "open source," document-oriented XML DTDs, such as the DocBook (used for technical documents) and TEI (used for scholarly analysis of electronic texts) DTDs. However, other document-oriented DTDs 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 consistency or 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.

The Dublin Core Metadata Element Set consists of elements for describing a wide range of networked resources. The elements have been established through consensus by professionals from librarianship, computer science, text encoding, and museum communities, and related fields of scholarship. The standard Dublin Core elements are: Title, Creator, Subject, Description, Publisher, Contributor, Date, Type, Format, Identifier, Source, Language, Relation, Coverage, and Rights.

Elements and attributes for XML digital signatures are incorporated in the Court Document 1.1 DTD from the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) . In general, XML digital signatures "provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere."

5.5. XML Namespaces and the XML Court Document 1.1 DTD

One fundamental weakness of DTD's is their inability to readily accommodate 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 an XML element from a separate domain. Because of their identical element names, the elements would be said to have "collided". XML namespaces solve this problem by permitting prefixes that can be resolved to URI's and affixing them 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 way to handle this difficulty is by declaring two DTDs: 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 core elements and attributes (although it does use XML namespaces with elements incorporated from other domains, such as Xlink attributes based on the XML Linking Language (XLink) Version 1.0 Recommendation and elements from the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) for XML digital signatures). 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:" might 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"/>.

5.6. Extending and 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, the following principles should be observed:

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

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

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

Extensions are allowed to this standard. All extensions must be readily identifiable by conforming applications. Conforming applications that do not understand the extension may ignore the extended element. Individually developed extension elements for new legal terms and definitions would not, of course, constitute any standard. To permit extended elements to be readily identified, the Court Document 1.1 DTD follows the same rules of extension 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, after which there must 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 in relationship to the Court Document 1.1 DTD.

The Court Document 1.1 DTD uses a special element that can contain any other element declared in the DTD (including new extension 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 "legalDefinition" element can be added to the DTD by adding the element declaration "<!ELEMENT legalDefinition_legalxml (#PCDATA)>." The new <legalDefinition_legalxml/> element can then be used within an <addIn/> element as follows: <addIn><legalDefinition_legalxml/></addIn>. It also is possible to add new parameter entities containing entire "modules" of new optional extension 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.

The Court Document 1.1 DTD uses parameter entities to accommodate extensions to the <person/>, <organization/>, and <paragraph/> elements. Elements extending the content models for these core Court Document 1.1 elements can first be declared in the DTD and then included in the extension parameter entities preceded by a "," or "|" connector as appropriate. Once they are included in these parameter entities, the newly declared elements will be added to the content models for the <person/>, <organization/>, and <paragraph/> elements. Thus, the extension element <occupation_legalxml/> could be added to the content model for the <person/> element by first declaring it in the DTD as "<!ELEMENT occupation_legalxml (#PCDATA)>" and then including it as an optional element in the extension parameter entity for the <person/> element (e.g. <!ENTITY % person.ANY ", occupation_legalxml?">). The new element will then extend the content model for the <person/> element (and for other elements containing the %person.ANY; parameter entity, such as <attorney/> or <witness/>).

A drawback to extending the Court Document 1.1 DTD and the Court Filing 1.1 DTD is that the extensions and the added in content models would not be standardized and may be ignored by applications that do not understand them. Thus, the extended Court Document 1.1 DTD or Court Filing 1.1 DTD would be usable across multiple jurisdictions except for their extension elements.

5.7. Assumptions and Requirements

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

  1. The Court Document 1.1 XML specification 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 specification 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, dates, 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, if any, including the type of electronic signature technology used, and optionally, a place and means 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 sub-components, including lists, phrases, quotations, footnotes, and multimedia objects; and

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

  3. The Court Document 1.1 XML specification 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 Electronic Court Filing 1.1 specification, particularly with respect to XML element and attribute names and content models for marking up similar information, while providing additional element and attribute names where the content models are not defined in the Court Filing 1.1 specification;

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

    • 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 any XML court documents ordered to be sealed or filed under seal by a court; and

    • a means for displaying a court document so it appears in the format the author intended at the time the author signed or submitted it.

6. DTD Specification

The Court Document 1.1 DTD defines the general entities, parameter entities, elements and attributes to be 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 this DTD. Validation against a DTD essentially helps to assure that a document contains the information an application would need, 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 provided by an author, such a person's birth date. However, validation against a DTD is a useful step to ensure that an XML document is not missing information important for a court document processing application.

The Court Document 1.1 DTD broadly organizes the 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, if any, used to 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 components are optional. Each of these six basic parts has its own child elements and content models to describe the information it contains.

6.1. Court Document 1.1 DTD

The proposed Court Document 1.1 DTD in ready-to-use form is at:

6.2. Character Entities

General entities declared in the 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.

6.3. Parameter Entities

The proposed XML Court Document 1.1 DTD 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 for DTD users 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. Official modifications to the Court Document 1.1 DTD require action by the appropriate OASIS Legal XML Court Filing Technical Committee and would be reflected in updates distinguished by higher version numbers and/or issue dates.

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 again and again 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 throughout the DTD where needed.

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 thus 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.

Finally, the Court Document 1.1 DTD uses parameter entities to accommodate extensions to the <person/>, <organization/>, and <paragraph/> elements. As discussed in more detail above, elements extending the content models for these core Court Document 1.1 elements can first be declared in the DTD and then included in the extension parameter entities. Once they are included in these parameter entities, the newly declared elements will be added to the content models for the <person/>, <organization/>, and <paragraph/> elements respectively.

The parameter entities in the Court Document 1.1DTD 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.

6.3.1. % person.ANY Parameter Entity 

<!ENTITY % person.ANY "">

This is a parameter entity for extending the <person> element. Any extension elements must be optional (i.e they must use a "?" or "*" occurrence indicator) so that existing documents will validate against the extended DTD. An optional extension element may be added to the content model for the <person/> element by first declaring it in the DTD and then including it as an optional element in this extension parameter entity preceded by an appropriate "connector" (e.g. <!ENTITY % person.ANY "| occupation_legalxml?">). The new element will then extend the content model for the <person/> element and other content models that include the %person.ANY; parameter entity.

6.3.2. % organization.ANY Parameter Entity 

<!ENTITY % organization.ANY "">

This is a parameter entity for extending the <organization> element. Any extension elements must be optional (i.e they must use a "?" or "*" occurrence indicator) so that existing documents will validate against the extended DTD. An optional extension element such as <registeredAgent_legalxml/>may be added to the content model for the <organization/> element by first declaring it in the DTD and then including it as an optional element in this extension parameter entity preceded by an appropriate "connector" (e.g. <!ENTITY % organization.ANY ", registeredAgent_legalxml?">). The new element will then extend the content model for the <organization/> element and other content models that include the %organization.ANY; parameter entity.

6.3.3. % paragraph.ANY Parameter Entity 

<!ENTITY % paragraph.ANY "">

This is a parameter entity for extending the <paragraph> element. Any extension elements must be preceded by and separated by an "|" connector because they will be part of the mixed content for a <paragraph> element. An optional extension element may be added to the content model for the <paragraph/> element by first declaring it in the DTD and then including it as an optional alternative element in this extension parameter entity preceded by the "|" connector (e.g. <!ENTITY % paragraph.ANY "| vehicle_legalxml?">). The new element will then extend the content model for the <paragraph/> element.

6.3.4. % XML Digital Signature Parameter Entities 

<!ENTITY % Method.ANY "">
<!ENTITY % Transform.ANY "">
<!ENTITY % SignatureProperty.ANY "">
<!ENTITY % KeyInfo.ANY "">
<!ENTITY % KeyValue.ANY "">
<!ENTITY % PGPData.ANY "">
<!ENTITY % X509Data.ANY "">
<!ENTITY % SPKIData.ANY "">
<!ENTITY % Object.ANY "">

These are parameter entities for extending the core XML digital signature elements. These parameter entities enable external/flexible content in XML digital signatures and are defined in the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) . Any extension elements must be preceded by and separated by an "|" connector. For example, an optional extension element may be added to the content model for the <dsig:KeyInfo/> element by first declaring the extension element in the DTD and then including it in the % KeyInfo.ANY; extension parameter entity (e.g. <!ENTITY % KeyInfo.ANY "| xki:XKIKeyValue">). The new element will then extend the content model for the <dsig:KeyInfo/> element.

6.3.5. % paragraph.model Parameter Entity 

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

This is a 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.

6.3.6. % paragraphGroup.model Parameter Entity 

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

This is a parameter entity for the content model of a paragraph group (i.e. a section containing one or more subsections or one or more paragraphs). This content model provides that an optional paragraph group title, if used, must immediately precede either one or more first-level paragraph subgroup(s) (i.e. subsections) or, alternatively, a <paragraph/> element, which may be immediately preceded by an optional <paragraphTitle/> element. An author must choose whether to use paragraph subgroups or simply to use paragraphs.

6.3.7. % dateTime.content Parameter Entity 

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

This is a 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 together 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. 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 31, 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.

6.3.8. % personName.content Parameter Entity 

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

This is a 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.

6.3.9. % personIdentification.content Parameter Entity 

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

This is a 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.

6.3.10. % organizationName.content Parameter Entity 

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

This is a 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.

6.3.11. % organizationIdentification.content Parameter Entity 

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

This is a 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.

6.3.12. % contact.content Parameter Entity 

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

This is a 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 for a person or organization, the various items must be given in the sequence listed. This content model includes the child elements used in the Court Filing 1.1 <actor/> element for describing contact information, but differs somewhat in terms of the grouping and sequence of those elements. For one thing, this parameter entity groups together and "modularizes" elements describing contact information. Additionally, it includes additional 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.

6.3.13. % postalAddress.content Parameter Entity 

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

This is a 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 and with the Justice and Public Safety XML Data Element Definitions (2002-04-26).

6.3.14. % documentMetadata.content Parameter Entity 

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

This is a parameter entity for the document metadata content model. This parameter entity holds elements to describe metadata about a court document that could 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 <documentTitle/>, <documentType/>, 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.

6.3.15. % caseMetadata.content Parameter Entity 

<!ENTITY % caseMetadata.content "(court | agency) , fullCaseNumber? , caseTitle? ,
relatedCase*">

This is a 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 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, and are often used by courts as index information to associate a document with a case file.

Multiple <relatedCase/> elements may be included to describe information about related cases that have been consolidated, transferred, appealed, and so forth. 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.

6.3.16. % paragraph.core Parameter Entity 

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

This is a parameter entity for the core contents of a paragraph or subparagraph. 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 thoughts or arguments 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 describe or markup particular items of information within a paragraph or subparagraph are described in this parameter entity. The subelements included in the <paragraph/> element can be extended with the % paragraph.ANY; parameter entity; this allows additional data elements to be declared in the DTD and used within paragraphs or subparagraphs.

6.3.17. % 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+)">

This is a parameter entity for the content model for information about the signer(s) of a court document. 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.

6.3.18. % notarization.content Parameter Entity 

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

This is a 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.

6.3.19. % content.attributes Parameter Entity 

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

This is a parameter entity for attributes of elements used for marking up text units or divisions 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 should be sealed or redacted.

6.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">

This is a 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 to ensure closer compatibility. This approach provides that elements appearing in both DTD's will have identical content models.

As described in the Court Filing 1.1 specification, "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, "codeLiteral," "codeSource," and "codeValue," are used to identify the appropriate code source (usually a formal standard), along with both the coded and literal forms of the data, "referenceDate" identifies the date on which the status was known to be accurate, and "status" provides a place to describe the status of this information.

6.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'">

This is a 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.

6.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">

This is a 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 provide a constraint to avoid potential problems from the use of inconsistent abbreviations.

6.4. Elements and Attributes

The elements and attributes in the Court Document 1.1 DTD are declared and organized in the following groups: elements for describing document metadata; common elements used throughout a court document to describe the names, contact information, and common participants in a legal proceeding (i.e. attorneys, judicial officers, witnesses, parties, etc.); elements for describing case metadata (i.e. information usually found in the captions of paper court documents); elements for marking up units 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 alphabetized list of the elements declared in the Court Document 1.1 DTD is included as Appendix B.

6.4.1. Elements to Describe the Basic Components of a Legal 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 components -- 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 the Court Document 1.1 DTD, but the signature, proof of service, and attachment parts are optional. An optional <electronicSignature/> element is also provided for electronic signature information. 

  • <!ELEMENT legal (courtDocument+)>

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

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

6.4.2. 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. 

  • <!ELEMENT documentMetadata (%documentMetadata.content;)>

    <documentMetadata/> contains the elements for describing metadata about the XML court document. Its child elements and content model are described in the %documentMetadata.content; parameter entity. Only the <documentTitle/>, <documentType/>, and <format/> elements are required. The remaining child elements are optional.

    The optional <displayInformation/> element contains information for displaying the XML court document. It has a content model substantially similar to the <attachedItemContent/> element with some additional attributes. It may contain display information, such as a stylesheet, as base-64 encoded text or, alternatively, as a <![CDATA[ (unparsed character data) section substantially similar to an attached item. The required "mimeType" attribute indicates how the contents of the <displayInformation/> element are to be interpreted (e.g., text/xsl, text/css, etc.). The optional "id" attribute describes the unique identifier for the display information. The optional "contentEncoding" attribute indicates the type of content encoding used and allows for future revisions. The optional "application" attribute names the application using the display information (e.g. Instant Saxon 6.2.2, msie 5.5, etc.), and the optional "description" attribute describes the general nature of the display information being provided (e.g. xslt stylesheet, etc.). 

  • <!ELEMENT documentIdentifier (#PCDATA)>

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

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

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

  • <!ELEMENT documentStatus (#PCDATA)>
<!ATTLIST documentStatus draft (draft | final ) 'draft'
privacy (sealed | redacted | restricted ) #IMPLIED
specialHandling (yes | no ) 'yes' >

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

  • <!ELEMENT documentTitle (#PCDATA)>

    <documentTitle/> contains the title or name given to the court document. It is a required element of the <documentMetadata/> element. The <documentTitle/> element is substantially similar to the Dublin Core "title" element and is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT documentType (#PCDATA)>
<!ATTLIST documentType documentCode CDATA #IMPLIED>

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

  • <!ELEMENT creator (person | organization)>

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

  • <!ELEMENT contributor (person | organization)>

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

  • <!ELEMENT submitter (party | attorney | judicialOfficer | administrativeOfficer | 
enforcementOfficer | notary | court | agency)>

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

  • <!ELEMENT description (#PCDATA)>

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

  • <!ELEMENT subject (#PCDATA)>

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

  • <!ELEMENT reference (link | image)*>
<!ATTLIST reference sourceTitle CDATA #IMPLIED
sourceCreator CDATA #IMPLIED
sourceDate CDATA #IMPLIED
sourceIdentifier CDATA #IMPLIED >

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

  • <!ELEMENT coverage (#PCDATA)>

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

  • <!ELEMENT language (#PCDATA)>

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

  • <!ELEMENT format (#PCDATA)>

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

  • <!ELEMENT displayInformation (#PCDATA)>
<!ATTLIST displayInformation id ID #IMPLIED
mimeType CDATA #REQUIRED
contentEncoding (base64 ) #IMPLIED
application CDATA #IMPLIED
description CDATA #IMPLIED >

    The optional <displayInformation/> element contains information for displaying the XML court document. It has a content model substantially similar to the <attachedItemContent/> element with some additional attributes. It may contain display information, such as a stylesheet, as base-64 encoded text or, alternatively, as a <![CDATA[ (unparsed character data) section substantially similar to an attached item.

    The required "mimeType" attribute indicates how the contents of the <displayInformation/> element are to be interpreted (e.g., text/xsl, text/css, etc.). The optional "id" attribute describes the unique identifier for the display information. The optional "contentEncoding" attribute indicates the type of content encoding used and allows for future revisions. The optional "application" attribute names the application using the display information (e.g. Instant Saxon 6.2.2, msie 5.5, etc.), and the optional "description" attribute describes the general nature of the display information being provided (e.g. xslt stylesheet, etc.).

6.4.3. 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 legal entities on the other. Information describing 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, more generic <actor/> element to contain information about both people and organizations.

Second, the Court Document 1.1 DTD defines separate elements describing the participants commonly 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 use to describe those involved in a court or administrative proceeding. The Court Document 1.1 DTD attempts to incorporate element names that are intuitive and meaningful to those who typically author or search for information in XML court documents. This makes it possible to describe the nature of a particular person's or organization's involvement in a legal proceeding more predictably and less ambiguously.

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 <person/> element. Two other "role" elements, <party/> and <victim/>, can refer either to human beings or to organizations. Thus, those elements contain child elements and content models for describing information applicable either to people or to organizations. 

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

    <party/> contains information about a person or organization that is a party in the proceeding. It contains either a single <person/>, <organization/>, or <inRem/> child element (and incorporates the respective 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. "Plaintiff," "Defendant," "Respondent," "Third-Party Defendant," etc. A more specific text 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 victim (person | organization)+>
<!ATTLIST victim id ID #IMPLIED>

    <victim/> contains information about a person or organization that is the victim of a crime or other wrong. 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 person (%personName.content; , %contact.content; , personIdentification? , role* 
%person.ANY;)>
<!ATTLIST person id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED>

    <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/>, and <role/> elements. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of a person; all other name, contact, or identification 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, redacted, or restricted.

    The %person.ANY; parameter entity is for incorporating extensions. An extension element must first be declared in the DTD and then included as an optional element in the %person.ANY; parameter entity declaration preceded by the appropriate "connector" (e.g. "|" or ","). The extension then will be automatically included in the content model for this element. 

  • <!ELEMENT attorney (%personName.content; , %contact.content; , barNumber* , 
personIdentification? , role* %person.ANY;)>
<!ATTLIST attorney id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED>

    <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/>, <personIdentification/>, and <role/> elements. Information about the name of an attorney must be provided; all other information is optional. The %person.ANY; parameter entity is for incorporating extensions. 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 judicialOfficer (%personName.content; , %contact.content; , personIdentification? , 
role* %person.ANY;)>
<!ATTLIST judicialOfficer id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED>

    <judicialOfficer/> contains the name, contact, identification, and role information for a judge, clerk of court, magistrate, or other 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 %person.ANY; parameter entity is for incorporating extensions. 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, redacted, or restricted. 

  • <!ELEMENT administrativeOfficer (%personName.content; ,
%contact.content; , 
personIdentification? , role* %person.ANY;)>
<!ATTLIST administrativeOfficer id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED>

    <administrativeOfficer/> contains the name, contact, identification, and role information for an administrative law judge, hearing officer, board member or other 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 %person.ANY; parameter entity is for incorporating extensions. 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, redacted, or restricted. 

  • <!ELEMENT enforcementOfficer (%personName.content; ,%contact.content; , 
personIdentification? , role* %person.ANY;)>
<!ATTLIST enforcementOfficer id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED>

    <enforcementOfficer/> contains the name, contact, identification, and role information for a police officer, sheriff, deputy, detective, or other 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 %person.ANY; parameter entity is for incorporating extensions. 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, redacted, or restricted. 

  • <!ELEMENT witness (%personName.content; , %contact.content; , personIdentification? , role* 
%person.ANY;)>
<!ATTLIST witness id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #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 %person.ANY; parameter entity is for incorporating extensions. 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, redacted, or restricted. 

  • <!ELEMENT notary (%personName.content; , %contact.content; , personIdentification? , role* 
%person.ANY;)>
<!ATTLIST notary id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #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 %person.ANY; parameter entity is for incorporating extensions. 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, redacted, or restricted. 

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

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

    <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 organization or state issuing the identification number. 

  • <!ELEMENT birthDate (#PCDATA)>
<!ATTLIST birthDate date CDATA #REQUIRED
%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 a required "date" attribute has been added for providing date information in machine readable, ISO 8601 format. 

  • <!ELEMENT age (#PCDATA)>

    <age/> contains the age of a person. It is not included in the Court Filing 1.1 DTD. 

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

    <comment/> contains the text of a comment. It is incorporated from the Court Filing 1.1 DTD. 

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

    <organization/> contains the name, contact, identification, and specific role information for an organization, such as a corporation, association, partnership, or similar legal entity. It uses many of 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, redacted, or restricted. 

  • <!ELEMENT organizationIdentification (%organizationIdentification.content;)>

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

    <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.

6.4.4. 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, specific 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 and can be generally classified 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 less ambiguous, and it uses "common" elements and content models consistently within those elements to describe name, contact, and more specific 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, such as demographic and physical description information, about both the people 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 specific role information and the choices required to mark up such information.

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. For consistency the Court Document 1.1 DTD incorporates from the Court Filing 1.1 <actor/> element many "horizontal" elements and content models for describing the names, contact information, and specific roles of 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, the Court Document 1.1 DTD 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 -- for example <attorney/>, <party/>, <witness/>, or <organization>. 

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

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

    <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 nickName (#PCDATA)>

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

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

    <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 firstName (#PCDATA)>
<!ATTLIST firstName %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 middleName (#PCDATA)>
<!ATTLIST middleName %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 lastName (#PCDATA)>
<!ATTLIST lastName %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 nameSuffix (#PCDATA)>
<!ATTLIST nameSuffix %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 organizationName (#PCDATA)>
<!ATTLIST organizationName %common.attributes;>

    <organizationName/> contains an organization's full name. It is based on the <entityName/> element in the Court Filing 1.1 DTD and also takes the optional common attributes -- "id", "type", "status", "referenceDate", "codeSource", "codeValue", and "codeLiteral". 

  • <!ELEMENT organizationUnit (#PCDATA)>
<!ATTLIST organizationUnit %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 abbreviatedName (#PCDATA)>
<!ATTLIST abbreviatedName %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 organizationAcronym (#PCDATA)>
<!ATTLIST organizationAcronym %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 postalAddress (%postalAddress.content;)>
<!ATTLIST postalAddress addressType (business | home | unknown ) 'business'
%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. 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 addressLine (#PCDATA)>
<!ATTLIST addressLine %common.attributes;>

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

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

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

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

  • <!ELEMENT state (#PCDATA)>
<!ATTLIST state stateCode (%state.codes; ) #IMPLIED
%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 "stateCode" 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 postalCode (#PCDATA)>
<!ATTLIST postalCode %common.attributes;>

    <postalCode/> contains the zip or postal code. It is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT country (#PCDATA)>
<!ATTLIST country %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 fullAddress (#PCDATA)>
<!ATTLIST fullAddress %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, such as <fullName/> and <fullTelephone/> in this DTD. 

  • <!ELEMENT telephone (telephonePrefix? , telephoneNumber , telephoneSuffix?)>
<!ATTLIST telephone %common.attributes;>

    <telephone/> contains the information for a telephone number. It is incorporated from the Court Filing 1.1 DTD. 

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

    <telephoneCountryCode/> contains the country code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD. 

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

    <telephoneCityCode/> contains the city code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD. 

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

    <areaCode/> contains the area code for a telephone number. It is incorporated from the Court Filing 1.1 DTD. 

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

    <telephoneSuffix/> contains the suffix, such as an extension, for a telephone number. It is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT fullTelephone (#PCDATA)>
<!ATTLIST fullTelephone telephoneType (business | home | mobile | pager | unknown )
'business'>

    <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 fax (telephone)>
<!ATTLIST fax %common.attributes;>

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

  • <!ELEMENT fullFax (#PCDATA)>
<!ATTLIST fullFax faxType (business | home | unknown ) 'business'>

    <fullFax/> contains a complete fax telephone number. It includes an enumerated attribute "faxType" to 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 email (#PCDATA)>
<!ATTLIST email emailType (business | home | mobile | unknown ) 'business'
%common.attributes;>

    <email/> contains an email address. It is incorporated from the Court Filing 1.1 DTD, but includes a new 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 uri (#PCDATA)><!ELEMENT uri (#PCDATA)>

    <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 role (roleName , roleWith*)>

    <role/> contains elements describing the specific role of a person, attorney, witness, judicial officer, organization, etc. and information about related persons or organizations. It is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT roleName (#PCDATA)>

    <roleName/> contains the name or description of the specific role taken by a person, attorney, witness, judicial officer, organization, etc. It is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT roleWith (organization | court | agency | party | person | attorney | witness | 
victim | judicialOfficer | administrativeOfficer | enforcementOfficer)?>
<!ATTLIST roleWith actorID IDREFS #IMPLIED
matterID IDREFS #IMPLIED>

    <roleWith/> contains a description of the person or organization with which a relationship exists and thus provides context for a specific role (e.g. <roleWith/><organization><organizationName>Legal XML, Inc.</organizationName></organization></roleWith>). As an alternative, <roleWith/> also has optional "actorID" and "matterID" attributes which can point to the "id" attributes of other person, organization, or case elements to indicate a relationship with them. For example, a relationship between a person and an organization can be described by using the "actorID" attribute. This element is based on the <roleWith/> element from the Court Filing 1.1 DTD. 

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

    <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 link (#PCDATA)>
<!ATTLIST link %xlink.attributes;>

    <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 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' >

    <image/> is an empty element for an image link using the global attributes from the XLink namespace for compatibility 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.

6.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. 

  • <!ELEMENT caseMetadata (%caseMetadata.content;)>
<!ATTLIST caseMetadata caseType CDATA #IMPLIED
id ID #IMPLIED>

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

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

  • <!ELEMENT court (((courtName , (courtDivision | courtDistrict | courtCircuit |
courtDepartment)* , abbreviatedName?) | abbreviatedName) , (venue | (%contact.content;))? , 
judicialOfficer*)>
<!ATTLIST court courtType CDATA #IMPLIED>

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

  • <!ELEMENT courtName (#PCDATA)>

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

  • <!ELEMENT courtDivision (#PCDATA)>

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

  • <!ELEMENT courtDistrict (#PCDATA)>

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

  • <!ELEMENT courtCircuit (#PCDATA)>

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

  • <!ELEMENT courtDepartment (#PCDATA)>

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

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

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

  • <!ELEMENT agency (((agencyName , (agencyOffice | agencyBureau | agencyDepartment | 
agencyBoard)* , (abbreviatedName | agencyAcronym)?) | abbreviatedName | agencyAcronym) , 
((venue) | (%contact.content;))? , administrativeOfficer*)>
<!ATTLIST agency agencyType CDATA #IMPLIED>

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

  • <!ELEMENT agencyName (#PCDATA)>

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

  • <!ELEMENT agencyAcronym (#PCDATA)>

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

  • <!ELEMENT agencyOffice (#PCDATA)>

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

  • <!ELEMENT agencyBureau (#PCDATA)>

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

  • <!ELEMENT agencyDepartment (#PCDATA)>

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

  • <!ELEMENT agencyBoard (#PCDATA)>

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

  • <!ELEMENT fullCaseNumber (#PCDATA)>

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

  • <!ELEMENT caseTitle (fullCaseTitle | (partyGroup | party | vs)+ | (inRe , party+))>

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

  • <!ELEMENT fullCaseTitle (#PCDATA)>

    <fullCaseTitle/> contains the full case title of the case or proceeding. 

  • <!ELEMENT inRem ((inRemName, aliasName*) , comment?)>
<!ATTLIST inRem id ID #IMPLIED
reference IDREF #IMPLIED
privacy (sealed | redacted | restricted ) #IMPLIED >

    <inRem/> contains information for an "in rem" party that is not a person or organization. It contains a required <inRemName/> element for the name of the "thing" involved, together with optional <aliasName/> and <comment/> elements. 

  • <!ELEMENT inRemName (#PCDATA)>

    <inRemName/> contains the name of an in rem "thing" involved in a legal proceeding. 

  • <!ELEMENT partyGroup (party+)>
<!ATTLIST partyGroup id ID #IMPLIED
partyType CDATA #REQUIRED>

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

  • <!ELEMENT vs (#PCDATA)>

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

  • <!ELEMENT inRe (#PCDATA)>

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

  • <!ELEMENT relatedCase ((court | agency) , fullCaseNumber? , caseTitle? , comment*)>
<!ATTLIST relatedCase id ID #IMPLIED
referenceCase IDREF #IMPLIED
relationshipType (consolidated | transferred | removed | appealed | 
other ) #REQUIRED>

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

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

6.4.6. Elements to Describe the Contents of the Body of a Legal 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. Finally, it contains the date the XML court document was submitted for filing.

Within paragraphs, the basic container of text in the body of an XML court document, the Court Document 1.1 DTD allows the use of various elements to distinguish footnotes, lists, citations, phrases, quotations, and similar items of text content. It also permits elements describing the participants in a case, such as the <person/> or <party/> elements, to appear 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. It is a convenient mechanism for customizing and extending the DTD by adding 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 since it completely opens up the element content models in the DTD. As a DTD matures, however, the use of ANY could become a detriment, because new markup is likely to be meaningless to applications created to process existing XML documents. The effort to develop a standard DTD for XML court documents is at an early stage. This justifies the flexibility afforded by the ANY content model of the <addIn/> element. 

  • <!ELEMENT documentBody ((paragraphGroup | (%paragraph.model;) | machineData)+ ,
dateTimeSigned)>

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

  • <!ELEMENT paragraphGroup (%paragraphGroup.model;)>
<!ATTLIST paragraphGroup id ID #REQUIRED
%content.attributes;>

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

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

  • <!ELEMENT paragraphGroupTitle (#PCDATA)>

    <paragraphGroupTitle/> contains the title of a paragraph group or subgroup. 

  • <!ELEMENT paragraphSubgroup1 (paragraphGroupTitle?,
(paragraphSubgroup2|(%paragraph.model;))+)>
<!ATTLIST paragraphSubgroup1 %content.attributes;>

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

  • <!ELEMENT paragraphSubgroup2 (paragraphGroupTitle?,
(paragraphSubgroup3|(%paragraph.model;))+)>
<!ATTLIST paragraphSubgroup2 %content.attributes;>

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

  • <!ELEMENT paragraphSubgroup3 (paragraphGroupTitle? ,
(%paragraph.model;)+)>
<!ATTLIST paragraphSubgroup3 %content.attributes;>

    <paragraphSubgroup3/> describes a third-level subgroup of paragraphs and must contain one or more paragraphs. It also contains an optional <paragraphGroupTitle/> element. The <paragraphSubgroup3/> element takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". 

  • <!ELEMENT paragraph (#PCDATA | subparagraphTitle | subparagraph1 | 
%paragraph.core; %paragraph.ANY;)*>
<!ATTLIST paragraph id ID #REQUIRED
%content.attributes;>

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

    The %paragraph.ANY; parameter entity permits extensions to the subelements that can be included within paragraphs. The additional subelements must be separately declared in the DTD and then must be listed in the declaration of the %paragraph.ANY; parameter entity described above.

    Like paragraph groups and subgroups, the <paragraph/> element takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". It also has a required "id" attribute. 

  • <!ELEMENT paragraphTitle (#PCDATA)>

    <paragraphTitle/> contains the title of a paragraph. 

  • <!ELEMENT subparagraph1 (#PCDATA | subparagraphTitle | subparagraph2 | 
%paragraph.core; %paragraph.ANY;)*>
<!ATTLIST subparagraph1 %content.attributes;>

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

  • <!ELEMENT subparagraphTitle (#PCDATA)>

    <subparagraphTitle/> contains the title of a subparagraph. 

  • <!ELEMENT subparagraph2 (#PCDATA | subparagraphTitle | subparagraph3 | 
%paragraph.core; %paragraph.ANY;)*>
<!ATTLIST subparagraph2 %content.attributes;>

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

  • <!ELEMENT subparagraph3 (#PCDATA | subparagraphTitle | %paragraph.core; %paragraph.ANY;)*>
<!ATTLIST subparagraph3 %content.attributes;>

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

  • <!ELEMENT addIn ANY>
<!ATTLIST addIn addInType CDATA #IMPLIED>

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

  • <!ELEMENT simpleCite (#PCDATA)>
<!ATTLIST simpleCite %content.attributes;>

    <simpleCite/> contains a complete text citation to a case, statute, or other legal authority. It also takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". 

  • <!ELEMENT keyword (#PCDATA)>
<!ATTLIST keyword id ID #IMPLIED
%content.attributes;>

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

  • <!ELEMENT literal (#PCDATA)>
<!ATTLIST literal id ID #IMPLIED
%content.attributes;>

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

  • <!ELEMENT phrase (#PCDATA)>
<!ATTLIST phrase id ID #IMPLIED
%content.attributes;>

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

  • <!ELEMENT quotation (#PCDATA | simpleCite | keyword | literal | phrase | date | link)*>
<!ATTLIST quotation id ID #IMPLIED
source CDATA #IMPLIED
%content.attributes;>

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

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

  • <!ELEMENT footnote (footnoteNumber , footnoteBody)>
<!ATTLIST footnote id ID #IMPLIED
label CDATA #IMPLIED
type CDATA #IMPLIED
subject CDATA #IMPLIED
title CDATA #IMPLIED>

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

  • <!ELEMENT footnoteNumber (#PCDATA)>

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

  • <!ELEMENT footnoteBody (#PCDATA | simpleCite | keyword | literal | phrase | quotation | date | 
link)*>

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

  • <!ELEMENT list (list | listItem)+>
<!ATTLIST list id ID #IMPLIED
%content.attributes;>

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

  • <!ELEMENT listItem (#PCDATA | simpleCite | keyword | literal | phrase | quotation | date | 
link | person | attorney | witness | judicialOfficer | administrativeOfficer | 
enforcementOfficer | organization | court | agency | victim | party | fullCaseNumber | 
caseTitle | relatedCase %paragraph.ANY;)*>
<!ATTLIST listItem %content.attributes;>

    <listItem/> contains a single item in a list. It has mixed content and can contain numerous other elements declared in the Court Document 1.1 DTD as well as parsed text. It also includes the %paragraph.ANY; parameter entity and thus can contain extension elements added to the DTD. It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". 

  • <!ELEMENT table (tableTitle? , tgroup)>
<!ATTLIST table id ID #IMPLIED
%content.attributes; >

    <table/> contains information organized in a formal table. It takes an optional "id" attribute and the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". It is based on the "table" element used in the DocBook DTD, which in turn is based on the CALS table model. The OASIS CALS table model describes tables using columns, rows, and cells. The <table/> element contains an optional <tableTitle/> element followed by a required <tgroup/> element. <table> uses child elements and attributes from the CALS table model and for consistency with that model and applications implementing it, the child elements of <table/> use a different naming convention than the one followed for other elements in this DTD. 

  • <!ELEMENT tableTitle (#PCDATA)>

    <tableTitle/> is an optional element containing the title of a table. 

  • <!ELEMENT tgroup (colspec* , spanspec* , thead? , tbody)>
<!ATTLIST tgroup cols CDATA #IMPLIED >

    <tgroup/> contains elements that describe the contents of a table. It is based on the CALS table model and contains optional <colspec/> and <spanspec> elements to describe columns and column spans, an optional <thead/> element to describe a heading row, and a required <tbody/> element to describe the body of a table. The "columns" attribute contains the number of columns in the table. 

  • <!ELEMENT colspec EMPTY>
<!ATTLIST colspec colname CDATA #IMPLIED
colnum CDATA #IMPLIED >

    <colspec/> is an optional empty element containing attributes describing the name and number of a column. The "colname" and "colnum" attributes are optional. 

  • <!ELEMENT spanspec EMPTY>
<!ATTLIST spanspec spanname CDATA #REQUIRED
namest CDATA #REQUIRED
nameend CDATA #REQUIRED >

    <spanspec/> is an optional empty element containing attributes to describe a horizontal span of columns. The "spanname" attribute contains the name of the horizontal span. The "namest" attribute contains the name of the starting or leftmost column of the span. The "nameend" attribute contains the name of the ending or rightmost column of the span. All attributes of <spanspec/> are required. 

  • <!ELEMENT thead (row)>

    <thead/> is an optional element containing a single heading row for a table. It must precede the rows in the body of the table. 

  • <!ELEMENT tbody (row+)>

    <tbody/> contains one or more required row elements comprising the body of a table. 

  • <!ELEMENT row (entry+)>

    <row/> contains a row in a table. It consists of one or more <entry/> elements. Within a <row/>, <entry/> elements are arranged sequentially in column order and may specify the column in which they appear. If no <entry/> elements are allocated to a column (i.e. if there are fewer <entry/> elements in a row than columns in a table), the "missing" <entry/> elements are assumed to be empty. 

  • <!ELEMENT entry (#PCDATA | simpleCite | keyword | literal | phrase | quotation | 
date | link | person | attorney | witness | judicialOfficer | administrativeOfficer | 
enforcementOfficer | organization | court | agency | victim | party | fullCaseNumber | 
caseTitle | relatedCase %paragraph.ANY;)*>
<!ATTLIST entry colname CDATA #IMPLIED
%content.attributes; >

    <entry/> describes a cell in a table row. Like the <listItem/> element, it has mixed content and can contain numerous other elements declared in the Court Document 1.1 DTD as well as parsed text. It also includes the %paragraph.ANY; parameter entity and thus can contain extension elements added to the DTD. The optional "colname" attribute may be used to specify the name of the table column in which the entry is to appear. Similarly the optional "spanname" attribute may be used to specify the name of a horizontal span in which the entry is to appear. <entry/> also takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". 

  • <!ELEMENT annotation (#PCDATA | simpleCite | keyword | literal | phrase | quotation | date | 
link)*>
<!ATTLIST annotation id ID #IMPLIED
description CDATA #IMPLIED
refersTo IDREFS #IMPLIED
creator CDATA #IMPLIED
%content.attributes; >

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

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

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

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

  • <!ELEMENT machineData (addIn)+>
<!ATTLIST machineData id ID #IMPLIED
%content.attributes; >

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

    The <machineData/> element takes the optional content attributes defined in the %content.attributes; parameter entity -- "label", "type", "subject", "language", or "privacy". The <machineData/> element also has an optional "id" attribute .

6.4.7. Elements to Describe the Signer(s) of a Legal 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. 

  • <!ELEMENT signers (signatory+ , notarization?)>

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

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

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

  • <!ELEMENT signatureLine (#PCDATA)>

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

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

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

  • <!ELEMENT notaryDate (#PCDATA)>
<!ATTLIST notaryDate date CDATA #REQUIRED >

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

  • <!ELEMENT notarySeal (#PCDATA)>

    <notarySeal/> contains the notary's seal. It has no attributes. 

  • <!ELEMENT notaryExpiration (#PCDATA)>
<!ATTLIST notaryExpiration date CDATA #REQUIRED >

    <notaryExpiration/> contains a text string giving the expiration date of the notary's authority. It has a required "date" attribute to contain date information in ISO 8601 number format.

6.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 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. 

  • <!ELEMENT proofOfService ((%paragraph.model;)+ , dateTimeServed , signatory)>

    <proofOfService/> contains the content model for a certificate or proof of service. It is an optional element, but if used it must contain one or more paragraphs followed by the date (and optionally the time) of service, and information about the signer of the certificate or proof of service. It has no attributes. 

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

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

6.4.9. Elements to Describe Attachments to a Legal XML Court Document

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. 

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

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

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

  • <!ELEMENT attachedItemContent (#PCDATA)>
<!ATTLIST attachedItemContent id ID #IMPLIED
mimeType CDATA #REQUIRED
contentEncoding (base64 ) #IMPLIED
href CDATA #IMPLIED>

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

6.4.10. Elements to Describe Electronic Signature Information

The elements and content models used in the optional <electronicSignature/> element describes information which applications can use to provide basic authentication and also contains information for digital signatures. The elements and content models for describing digital signature information are incorporated from the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) and use the XML namespace prefix "dsig." 

  • <!ELEMENT electronicSignature (dataIntegrity?, authentication? , dsig:Signature?)+>

    <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 <authentication/> element provides for authentication by means of a user id and password in keeping with the Court Filing 1.1 DTD. As previously noted, the <dsig:Signature/> element is incorporated from the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12). 

  • <!ELEMENT dataIntegrity (#PCDATA)>
<!ATTLIST dataIntegrity bindingType (none | hash | authenticationCode | digitalSignature | 
symmetricKey | other ) #REQUIRED >

    <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 binding can be selected. 

  • <!ELEMENT authentication (userIdentification , password?)>
<!ATTLIST authentication userIdentification CDATA #IMPLIED
password CDATA #IMPLIED
authenticationType (none | passwordPlain | passwordCrypto | X-509 | 
biometric | signatureDynamics | signatureImage | other ) #REQUIRED >

    <authentication/> contains information for authenticating an XML court document. The <userIdentification/> and optional <password/> elements provide for authentication by means of a user id and password for consistency with the Court Filing 1.1 DTD. The <authentication/> element has a required "authenticationType" enumerated attribute to indicate the type of authentication used. 

  • <!ELEMENT userIdentification (#PCDATA)>

    <userIdentification/> is the user name or logon identifier being authenticated by the password. It is incorporated from the Court Filing 1.1 DTD. 

  • <!ELEMENT password (#PCDATA)>

    <password/> is the secret word known to the user who is identified by userIdentification. It is incorporated from the Court Filing 1.1 DTD.

  • XML Digital Signature Elements and Attributes 

    <!ELEMENT dsig:Signature (dsig:SignedInfo , dsig:SignatureValue , dsig:KeyInfo? , dsig:Object*)>
<!ATTLIST dsig:Signature 
xmlns:dsig CDATA#FIXED 'http://www.w3.org/2000/09/xmldsig#'
Id ID#IMPLIED>

<!ELEMENT dsig:SignedInfo (dsig:CanonicalizationMethod , dsig:SignatureMethod ,
dsig:Reference+)>
<!ATTLIST dsig:SignedInfo Id ID #IMPLIED >

<!ELEMENT dsig:CanonicalizationMethod (#PCDATA)*>
<!ATTLIST dsig:CanonicalizationMethod Algorithm CDATA #REQUIRED >

<!ELEMENT dsig:SignatureMethod (#PCDATA | dsig:HMACOutputLength)*>
<!ATTLIST dsig:SignatureMethod Algorithm CDATA #REQUIRED >

<!ELEMENT dsig:Reference (dsig:Transforms? , dsig:DigestMethod , dsig:DigestValue)>
<!ATTLIST dsig:Reference Type CDATA #IMPLIED
URI CDATA #IMPLIED
Id ID #IMPLIED >

<!ELEMENT dsig:Transforms (dsig:Transform+)>

<!ELEMENT dsig:Transform (#PCDATA | dsig:XPath)*>
<!ATTLIST dsig:Transform Algorithm CDATA #REQUIRED >

<!ELEMENT dsig:XPath (#PCDATA)>

<!ELEMENT dsig:DigestMethod (#PCDATA)*>
<!ATTLIST dsig:DigestMethod Algorithm CDATA #REQUIRED >

<!ELEMENT dsig:DigestValue (#PCDATA)>

<!ELEMENT dsig:KeyInfo (#PCDATA | dsig:KeyName | dsig:KeyValue | dsig:RetrievalMethod | 
dsig:X509Data | dsig:PGPData | dsig:SPKIData | dsig:MgmtData %KeyInfo.ANY;)*>
<!ATTLIST dsig:KeyInfo Id ID #IMPLIED >

<!ELEMENT dsig:KeyName (#PCDATA)>

<!ELEMENT dsig:KeyValue (#PCDATA | dsig:DSAKeyValue | dsig:RSAKeyValue)*>

<!ELEMENT dsig:MgmtData (#PCDATA)>

<!ELEMENT dsig:RetrievalMethod (dsig:Transforms?)>
<!ATTLIST dsig:RetrievalMethod Type CDATA #IMPLIED
URI CDATA #REQUIRED >

<!ELEMENT dsig:X509Data ((dsig:X509IssuerSerial | dsig:X509SKI | dsig:X509SubjectName | 
dsig:X509Certificate | dsig:X509CRL)+)>

<!ELEMENT dsig:X509IssuerSerial (dsig:X509IssuerName , dsig:X509SerialNumber)>

<!ELEMENT dsig:X509IssuerName (#PCDATA)>

<!ELEMENT dsig:X509SubjectName (#PCDATA)>

<!ELEMENT dsig:X509SerialNumber (#PCDATA)>

<!ELEMENT dsig:X509SKI (#PCDATA)>

<!ELEMENT dsig:X509Certificate (#PCDATA)>

<!ELEMENT dsig:X509CRL (#PCDATA)>

<!ELEMENT dsig:PGPData ((dsig:PGPKeyID , dsig:PGPKeyPacket?) | (dsig:PGPKeyPacket))>

<!ELEMENT dsig:PGPKeyPacket (#PCDATA)>

<!ELEMENT dsig:PGPKeyID (#PCDATA)>

<!ELEMENT dsig:SPKIData (dsig:SPKISexp)>

<!ELEMENT dsig:SPKISexp (#PCDATA)>

<!ELEMENT dsig:Object (#PCDATA | dsig:Signature | dsig:SignatureProperties |
dsig:Manifest)*>
<!ATTLIST dsig:Object Encoding CDATA #IMPLIED
MimeType CDATA #IMPLIED
Id ID #IMPLIED >

<!ELEMENT dsig:Manifest (dsig:Reference+)>
<!ATTLIST dsig:Manifest Id ID #IMPLIED >

<!ELEMENT dsig:SignatureProperties (dsig:SignatureProperty+)>
<!ATTLIST dsig:SignatureProperties Id ID #IMPLIED >

<!ELEMENT dsig:SignatureProperty (#PCDATA)*>
<!ATTLIST dsig:SignatureProperty Id ID #IMPLIED
Target CDATA #REQUIRED >

<!ELEMENT dsig:HMACOutputLength (#PCDATA)>

<!ELEMENT dsig:DSAKeyValue ((dsig:P , dsig:Q)? , dsig:G? , dsig:Y , dsig:J? , 
(dsig:Seed , dsig:PgenCounter)?)>

<!ELEMENT dsig:P (#PCDATA)>

<!ELEMENT dsig:Q (#PCDATA)>

<!ELEMENT dsig:G (#PCDATA)>

<!ELEMENT dsig:Y (#PCDATA)>

<!ELEMENT dsig:J (#PCDATA)>

<!ELEMENT dsig:Seed (#PCDATA)>

<!ELEMENT dsig:PgenCounter (#PCDATA)>

<!ELEMENT dsig:RSAKeyValue (dsig:Modulus , dsig:Exponent)>

<!ELEMENT dsig:Modulus (#PCDATA)>

<!ELEMENT dsig:Exponent (#PCDATA)>

<!ELEMENT dsig:SignatureValue (#PCDATA)>
<!ATTLIST dsig:SignatureValue Id ID #IMPLIED >

    <dsig:Signature/> is the root element for XML digital signatures. The W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) provides the current specification regarding XML digital signatures and should be consulted for a detailed explanation. Elements incorporated from the W3C XML digital signature Recommendation use the XML namespace prefix "dsig." In general, XML digital signatures "provide integrity, message authentication, and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere."

7. Future Developments

Work to develop standards for XML court documents is ongoing. Updating of this Candidate Specification is anticipated. It 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 DTD's. 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.

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;" 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 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 .

B. Court Document 1.1 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.

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 may 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 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 capable 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.

D. Notices

Copyright © The Organization for the Advancement of Structured Information Standards [OASIS] 2001, 2002. All Rights Reserved.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification, can be obtained from the OASIS Executive Director.

OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to implement this specification. Please address the information to the OASIS Executive Director.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to OASIS, except as needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

References

Normative

[RFC 2119] S. Bradner. RFC 2119: Key words for use in RFCs to Indicate Requirement Levels . IETF (Internet Engineering Task Force). 1997.

[XML] T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler. XML 1.0 Specification (2nd ed. October, 2000) . W3C (World Wide Web Consortium). 2000.

[DSIG] M. Bartel, J. Boyer, B. Fox, B. LaMacchia, E. Simon. W3C's XML-Signature Syntax and Processing Recommendation (February 12, 2002) . W3C (World Wide Web Consortium). 2002.

[XLINK] S. DeRose, E. Maler, D. Orchard. XML Linking Language (XLink) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 2001.

Other

[CF1.1] OASIS Legal XML Member Section Electronic Court Filing 1.1 Proposed Standard (2002-07-22) . Legal XML. 2002.

[DCES] Dublin Core Metadata Element Set, Version 1.1: Reference Description . DCMI (Dublin Core Metadata Initiative). 1999.

[CSS2] B. Bos, H. W. Lie, C. Lilley, I. Jacobs. Cascading Style Sheets, level 2 ("CSS2") . W3C (World Wide Web Consortium). 1998.

[XSLT] J. Clark. XSL Transformations (XSLT) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 1999.

[XSL] S. Adler, et al. Extensible Stylesheet Language (XSL) Version 1.0 Recommendation . W3C (World Wide Web Consortium). 2001.