[Cache from http://www.apltwo.ct.state.az.us/legalXML/CourtDocument11/Court_Document_11.html; please use this canonical URL/source if possible.]
This Draft Standard provides the draft Legal XML Court Document 1.1 DTD. The Court Document 1.1 DTD proposes standard XML elements and attributes and content models for using XML to mark up court documents from the widest possible range of jurisdictions. It substantially modifies the previously proposed draft Court Document 1.0 DTD (2001-06-21).
This is a Court Filing Work Group Draft Standard for review and discussion by interested members.
This document is intended to describe the information required for marking up the contents and structure of electronic court documents using XML.
This document is a Proposed Standard collaboratively developed by the COSCA/NACM Joint Technology Committee and the Legal XML Court Filing Workgroup.
This proposed standard Court Document 1.1 DTD is the product of a consensus process. Many items are the result of input from multiple viewpoints. It also borrows extensively from the Legal XML Court Filing 1.1 standard (2002-02-18). This proposed standard is a work in progress and further development of the standard is anticipated and welcome.
Within this document the terms "shall" or "must" describe mandatory items. The term "may" describes optional items.
This proposed standard conforms to the XML 1.0 Specification (2nd ed. October, 2001) ( http://www.w3.org/TR/REC-xml.html ).
This proposed standard adheres to the conventions followed in the Legal XML Court Filing 1.1 standard with respect to element and attribute naming and the capitalization of XML tags.
This document describes an XML DTD for validating the syntax of XML court documents. This document itself does not set out the proposed Court Document 1.1 DTD in a format suitable for use. For instance, this document includes explanations of various elements and attributes used in the proposed DTD that are not formatted as comments. It also uses whitespace and color to make the entity, element, and attribute declarations used in the DTD easier to read. However, Section 2.1 contains a link to the proposed Court Document 1.1 DTD in usable format.
This document also contains a simplified version of the full Court Document 1.1 DTD. The simplified Court Document 1.1 DTD seeks to provide a smaller and somewhat easier to use subset of the full Court Document 1.1 DTD. Documents written using the simplified Court Document 1.1 DTD will be completely valid against the full Court Document 1.1 DTD (although the reverse will not necessarily be true). It is assumed that the simplified Court Document 1.1 DTD will be suitable for use in many instances where the more richly structured mark up of the full Court Document 1.1 DTD is not needed.
All appendices are non-normative and may contain well formed, valid example XML court documents for purposes of illustration only. If an inconsistency arises between an example and the Court Document 1.1 DTD, the DTD shall control.
Creating XML documents is different from authoring documents in a word processor. The author of an XML document must not only create the text of the document but also must select and include the appropriate XML markup that describes that text. XML authoring applications can simplify the process by providing menus, forms, buttons, or similar ways for an author to identify and designate the appropriate tags to describe the text content of an XML document, but it nevertheless takes more physical and mental effort (and extra time) to create an XML document than to create a text document in a word processor. Thus, facilitating ease of use in creating XML court documents has been a primary consideration with respect to the Court Document 1.1 DTD.
The Court Document 1.1 DTD favors relative simplicity, consistency, and flexibility in its XML content models over comprehensive detail and rigid structure. The Court Document 1.1 DTD assumes that most of the information to create XML court documents will come from human authors -- lawyers, judges, clerks, paralegals, and legal secretaries -- rather than from machine sources, such as databases. It further assumes that authors will create documents that communicate, explain, argue, clarify, and decide legal issues and concepts arising in a specific case, and that such documents will not be readily reusable in other contexts or cases. This standard also assumes that the basic structures of ordinary grammar - the sentence and paragraph (as opposed to a comprehensive set of data elements) - are the preferable containers for text expressing legal ideas and concepts in XML court documents. Consequently, to promote ease of use, the Court Document 1.1 DTD offers a relatively small set of XML elements and attributes, strives for consistency and intuitiveness with respect to element and attribute names, favors parallel design of XML tags used for marking up similar content, and seeks to avoid requiring choices that might be confusing. A simplified Court Document 1.1 DTD also is offered as a further effort to realize these goals.
A fundamental characteristic of XML markup is that it explicitly distinguishes the use of markup to describe the structure and semantic content of a document from information describing the way the structured document will be displayed to a reader. This separation of content from display is often troublesome for human authors accustomed to controlling the appearance as well as the content of a document. Authors using modern "what-you-see-is-what-you-get" word processors are able to impose structure on a document by changing the appearance of the text. They may underline or italicize words for emphasis or use different fonts or indentation (white space) for headings, titles, or subparts of a section or paragraph. The display format an author uses imparts structure by changing the appearance of the text in ways that a human reader, but not a machine, can more or less reliably understand.
In contrast, structured markup languages, such as XML, use named elements instead of font changes, indentation, and the like to describe the structure and semantics of the text in a document. The markup tags (rather than formatting) impart structure. For example, the XML element <documentTitle/> describes the text it contains as a document title, but says nothing about the font or spacing that should be used to display it. Structured markup, however, makes it possible for software to interpret and process documents for many different purposes. Software applications can reliably retrieve and process text information from structured documents in predictable, useful ways. For instance, it is possible to publish the contents of a structured document in a wide variety of formats, such as HTML, print, braille, or even audio using exactly the same source document.
Because XML documents separate information about content and structure from information about display, a separate tool called a stylesheet is typically used to display the structured form. Information regarding the fonts, margins, indentation and the like for displaying the structured document is collected and contained in the stylesheet. Many XML-capable web browsers and other applications use Cascading Style Sheets ("CSS") or stylesheets written in the eXtensible Stylesheet Language ("XSL") for this purpose. For example, a stylesheet can contain information regarding the font style, font size, and indentation for displaying the contents of a <documentTitle/> element.
This standard assumes that stylesheets usually will be used to display the contents of XML court documents to readers, and the samples in the appendices to this document include sample stylesheets for purposes of illustration only. The Court Document 1.1 standard does not attempt to establish any standard stylesheets for displaying the contents of XML court documents. It does assume, however, that XML elements for describing the structure and contents of court documents should permit such documents to be displayed by stylesheets in a form substantially similar to the paper court documents with which human readers are familiar. It is assumed that a court or agency may develop standard stylesheet(s) to display the contents of XML court documents using margins, fonts, indentation, etc. in the way the court prefers. This standard also assumes that an author may include a stylesheet with an XML court document as an attachment if there is a need or desire to include display information. A receiving application will then need to extract the stylesheet and apply it to the XML content for purposes of display.
"Court documents" generally are the category of documents filed with courts or administrative agencies in formal legal proceedings, such as civil or criminal lawsuits or administrative hearings. Court documents consist of documents such as pleadings, orders, briefs, motions, and similar items. They also include documents related to the case that may never actually be filed in a court, such as discovery documents, disclosure statements, and offers of judgment. This standard assumes that court documents possess certain common features in terms of their basic organization and structure. It also assumes that the basic organization and structure of information in court documents can be described using XML elements and attributes.
The Court Document 1.1 DTD proposes standard XML elements and attributes and content models for using XML to mark up court documents from the widest possible range of jurisdictions. Its content models are derived primarily from the information and structures found in paper court documents. In this regard, the Court Document 1.1 DTD is basically "document-centric" as opposed to "data-centric" (although information in some parts of a court document, such as a case caption, is certainly "data-centric").
Court documents not only share a general structure -- they typically contain technical legal terms and concepts and various types of data interspersed thoughout the body of the document as phrases, quotations, citations, lists, and the like. These technical legal terms and concepts and other data, such as names, addresses, and dates, can be described and categorized in many different ways. It is possible in concept to define XML mark up tags to describe technical legal terms such as "due process", "burden of proof," "malice," or "estoppel" when they appear in XML court documents. As a practical matter, however, different areas of legal practice use their own particular vocabularies.
Criminal, domestic, immigration, real estate, tax, and similarly "specialized" areas of legal practice use scores of special legal terms to communicate substantive and procedural legal concepts typically having precise technical meanings for those who practice or work in those fields. Coming up with a comprehensive set of XML tags for marking up all the technical legal terms and concepts that can appear in a court document would presumably require hundreds of XML tags, which would result in a large and complicated DTD. A large and complicated DTD is likely to be more difficult to learn and use. Completing the extensive data dictionaries that would be needed might take years. Thus, the Court Document 1.1 DTD does not attempt to define XML markup for comprehensive "data sets" of all the specialized legal terms and concepts that might appear in a court document, although it contemplates that they may emerge over time.
The Court Document 1.1 DTD marks a beginning by describing the general organization and structure of information in court documents. It also includes some general tags for marking up phrases, quotations, lists and similar items typically appearing in the body of court documents. This standard assumes, however, that more specialized XML vocabularies used in particular areas of legal practice will be developed over time and that a means should be provided to allow authors to mark up specialized legal terms and phrases within XML court documents. The Court Document 1.1 DTD itself does not attempt to establish a comprehensive XML vocabulary for describing and categorizing all the specialized substantive and procedural legal terms that can appear as data in a court document -- it simply provides a basic framework and general starting point from which further development can proceed. For example, it is assumed that a standard XML or other schema for validating XML court documents will be developed in addition to or as a replacement for the Court Filing 1.1 DTD.
The Court Document 1.1 DTD and the Legal XML Court Filing 1.1 DTD serve different though related purposes. The Court Filing 1.1 DTD defines data elements needed for the electronic filing of various types of electronic documents by court case management systems. It provides a standard XML vocabulary to describe the data required for electronic court filing and the structure of that information. In this regard, it uses XML to promote data interchange with court case management systems and their accompanying data bases. However, it does not include information regarding the contents or structure of any pleading or other court document.
The Court Document 1.1 DTD in contrast defines XML elements and attributes for marking up the contents and structure of court documents. It defines information useful for document management systems, for stylesheets to display XML court documents to human readers, for basic textual analysis of court documents, and other purposes, possibly including the automated generation and processing of some court documents. However, it does not include all the information needed for the electronic filing and docketing of a pleading or other court document in a case management system. It assumes and expects that XML court documents will not be electronically filed directly with a court, but by means of applications implementing the Court Filing 1.1 standard.
This standard assumes that XML court documents, when included within XML electronic filings conforming to the Court Filing 1.1 standard, will be base-64 encoded text or unparsed character data. The Court Filing 1.1 DTD contains a <documentContent/> element having a #PCDATA content model which can contain a hyperlink, a base-64 encoded BLOB (particularly useful when the document being filed is a binary file), or text. An obvious problem with simply placing any XML content, XML tags and all, directly inside the Court Filing 1.1 <documentContent/> element is that this will cause validation errors. An XML validating parser will recognize that the Court Filing 1.1 DTD permits only parsed character data (text that does not contain any XML delimiters) to occur within the <documentContent/> element, but not any XML tags. Consequently, any XML document, including an XML court document, needs to be base-64 encoded for inclusion in a Court Filing 1.1 XML filing to avoid validation errors. Base-64 encoding removes the < and & characters and other XML delimiters recognized as such by the parser.
Alternatively, it also is possible to include an XML document, XML tags and all, within a <![CDATA[ (unparsed character data) section within the <documentContent/> element. Marking a section of text as CDATA in effect turns off the parser so that the presence of XML delimiters in element tags will not trigger parsing errors. The proposed Court Document 1.1 DTD assumes that it will be possible to include XML court documents within XML Court Filing 1.1 filings using either of these techniques without creating any compatibility problems. Of course, XML court documents will then need to be extracted from the Court Filing 1.1 XML filing for further processing.
The Court Document 1.1 DTD also favors consistency with the Court Filing 1.1 XML standard from which it borrows heavily. Many of the XML elements and attributes in the Court Filing 1.1 DTD, particularly those that contain only text data, are common to elements and attributes in the Court Document 1.1 DTD. Such elements from the Court Filing 1.1 DTD have been fully incorporated in the Court Document 1.1 DTD to the extent they are consistent with the goals of simplicity, consistency, and flexibility favored by the Court Document 1.1 DTD.
However, not all elements specified in the Court Filing 1.1 standard have been included in the Court Document 1.1 DTD. A few have been modified to promote the goals of simplicity, consistency, and flexibility to make the Court Document 1.1 DTD easier to use. Such modifications and the rationale for them are noted where they occur. When discrepancies between element content models in this standard and the Court Filing 1.1 element content models exist, this standard applies only with respect to XML court documents.
The Court Document 1.1 DTD employs some of the techniques used in other "open source," document-oriented XML DTD's, such as the DocBook (used for technical documents) and TEI (used for scholarly analysis of electronic texts) DTD's. However, other document-oriented DTD's, even in their simplified forms, are somewhat complicated and would require substantial modification to be useful for marking up court documents. Thus, the Court Document 1.1 DTD does not attempt to achieve compatibility with any other DTD besides the Court Filing 1.1 DTD .
To provide XML mark up tags for describing metadata about XML court documents, the Court Document 1.1 DTD uses elements based on the Dublin Core Metadata Element Set, Version 1.1 . The Dublin Core Metadata Initiative (DCMI) is an organization dedicated to promoting the widespread adoption of interoperable metadata standards for describing resources that enable more intelligent information discovery systems. Thus, the Court Document 1.1 DTD incorporates an available standard for marking up document metadata instead of offering its own metadata tags.
One fundamental weakness of DTD's is their inability to readily accomodate the use of XML namespaces , which became a standard after the emergence of the XML 1.0 standard. XML namespaces provide a way to preserve the uniqueness of XML element and attribute names using Uniform Resource Identifiers ("URI's"). XML namespaces make it possible for an XML document to use elements and attributes from different domains without the confusion that would result if an XML element from one domain had a different content model, but the identical element name as (and thus "collided" with), an XML element from a separate domain. XML namespaces solve this problem by permitting prefixes that can be resolved to URI's to be affixed to element and attribute names.
Unfortunately, changing an XML element or attribute name declared in a DTD by affixing a namespace prefix makes a document invalid against the DTD. A validating parser will not recognize the new element name containing the namespace prefix since the prefixed element is not declared in the DTD and will not validate the XML document containing it.
One theoretical way to handle this difficulty is by declaring two DTD's - one without XML namespaces and another one with XML namespaces. The Court Document 1.1 DTD does not adopt this solution and does not declare or use XML namespaces with its elements and attributes. However, when the use of an XML namespace with Court Document 1.1 XML elements or attributes is desired (for example with XML documents validated against an XML Schema rather than a DTD), the XML namespace URI "http://www.legalxml.org/ns/courtdocument11.dtd" must be used and the namespace prefix "cd:" may be used. For example, if an XML namespace is used with the XML elements and attributes defined in this DTD, the Court Document 1.1 element <courtDocument/> would become <cd:courtDocument xmlns:cd = "http://www.legalxml.org/ns/courtdocument11.dtd"/> .
In general, it is not particularly easy to customize a DTD and maintain its compatibility with existing documents. Changing the repetition, omissibility, or alternation of elements in a DTD may make existing documents invalid against the modified DTD. To preserve compatibility with existing documents, keeping the following principles in mind may be helpful:
Extensions are allowed to this standard. All extensions must be readily identifiable by conforming applications. Conforming applications that do not understand the extension may ignore the extended element and its content. To permit extended elements to be readily identified, the Court Document 1.1 DTD follows the same convention used in the Court Filing 1.1 DTD. Extensions must be identified by the appearance of an underscore character, "_", at the end of the new element name. Following the underscore, there shall be a series of characters identifying the individual or organization creating the extension. Thus, it would be possible to add a new <province_legalxml/> element as an optional alternative to the <state/> element in the Court Document 1.1 DTD without affecting the validity of older documents.
The Court Document 1.1 DTD uses a special element that can contain any other element declared in the DTD (including new elements) -- the <addIn/> element. The <addIn/> element can appear only within paragraphs or within the <machineData/> element of an XML court document. Because the <addIn/> element has an ANY content model, it can contain any of the other elements declared in the Court Document 1.1 DTD. ANY permits authors to include and use new elements in the DTD. For example, a "legalTerm" element can be added to the DTD by adding the element declaration "< !ELEMENT legalTerm_legalxml (#PCDATA)>." The new <legalTerm_legalxml/> element can then be used within an <addIn/> element as follows: <addIn> <legalTerm_legalxml/> </addIn> . Alternatively, it also is possible to add new parameter entities containing entire "modules" of new optional elements and content models to the DTD and then to use any of the new elements within an <addIn/> element. The ANY content model can be useful in the early stages of DTD development because it completely opens up the element content models in the DTD. As a DTD matures, however, the use of ANY can become a detriment, because new markup added to the DTD may be meaningless to applications created to process existing XML documents.
The proposed Court Document 1.1 DTD is based on the following specific assumptions and requirements:
The Court Document 1.1 DTD defines the general entities, parameter entities, elements and attributes used in marking up XML court documents. XML documents containing elements, attributes, or content models not defined in the Court Document 1.1 DTD will not be valid against the DTD. Validation against the DTD essentially helps to assure that a document contains the information an application needs, in a form the application will accept, to process the document. Validation against a DTD will not reveal all the erroneous data in an XML document. For instance, it will not detect typos or misspellings, and it will not verify the accuracy of information, such a person's birth date, provided by an author. However, validation against a DTD is a useful step to assure that an XML document is not missing information important for a processing application.
The Court Document 1.1 DTD broadly organizes the information in an XML court document into six basic parts -- document metadata, case metadata, the document body, signature information, the certificate or proof of service, and attachments. An optional <electronicSignature/> element is also provided for describing information about the electronic signature technology used to electronically sign an XML court document. Certain information within the document metadata, case metadata, and document body portions of an XML court document must always be present in order for a court document to be valid against this DTD, but the signature, proof of service, and attachment portions are optional. Each of these basic parts uses its own child elements and content models to describe the information it contains.
The Simplified Court Document 1.1 DTD omits a number of the elements and attributes present in the full Court Document 1.1 DTD in order to provide a somewhat simpler set of elements and content models. For instance, it omits the %common.attributes parameter entity, <nickname/> , <partyGroup/> , paragraph subgroup, <machineData/> , and identification elements present in the full Court Document 1.1 DTD. It also simplifies the <caseTitle/> element and omits the <telephone/> and <fax/> (but not the <fullTelephone/> or <fullFax/> ) elements. It does not contain a <notarization/> element and omits some other mark up tags that are not likely to be used in most XML court documents. The aim is to provide a simplified DTD that can be used for validating basic XML court documents which do not require the richer markup provided by the full Court Document 1.1 DTD. Documents valid against the simplified DTD will be valid against the full DTD, although the reverse will not always be true.
| Date | DTD |
|---|---|
| 2002-05-31 | courtdocument11.dtd |
| 2002-05-31 | scourtdocument11.dtd |
General entities declared in the Court Document 1.1 DTD and simplified Court Document 1.1 DTD are listed in Appendix A and are derived from the corresponding ISO 8879 standard entity set as incorporated in the Simplified DocBook DTD v4.1.2.5 . The general entities permit various characters such as the section, paragraph, currency signs, fractions, and other symbols and signs to be used within XML court documents. For instance, ¶ can be used in an XML court document for the paragraph symbol and § 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.
The proposed XML Court Document 1.1 DTD liberally uses parameter entities to declare standard content models for many of its elements and attributes. The use of parameter entities permits the elements and attributes to be organized within the DTD in a more modular way and also makes customizing and extending the DTD easier. Using parameter entities in a DTD makes it easier to maintain, customize and extend the DTD without requiring that the DTD be entirely re-written. A new parameter entity "module" can be declared that contains the new elements or new content models. The new parameter entity can then be added to the DTD as an alternative to or replacement for the one affected by the changes or to make new elements or attributes available for use.
When internal parameter entities are used to declare a standard content model in a DTD, the standard content model then can be referred to later in the DTD simply by a reference to the internal parameter entity. This avoids the need to repeat the full content model within the DTD. For instance, if there is a group of standard attributes that can be used with a number of different elements in the DTD, the standard attributes can be declared once in one parameter entity. Then the declaration for elements using that group of standard attributes can simply refer to the parameter entity. In this sense parameter entities are re-usable modules of mark up that can be applied at various places in the DTD.
Using parameter entities also makes it possible to "flatten" and simplify the hierarchical organization of elements in a DTD. Instead of using a "container" element to hold additional elements at a second "tier," the additional elements can be collected in a parameter entity. When needed, the collection of elements can be declared simply by referring to the parameter entity and avoiding the need for a higher tier element to contain them. As a general rule, a "flatter" DTD contains fewer elements, which makes it easier to learn and use. The parameter entities in the Court Document 1.1 DTD are intended to serve that goal.
The parameter entities in the Court Document 1.1 and simplified Court Document 1.1 DTD's are declared after the general entities. Primarily, they describe the content models for the names and contact information of people and organizations; document and case metadata elements; elements used in paragraphs and paragraph groups, signatures, and attachments; and attributes common to various elements in the DTD.
Parameter entity for the content model for a paragraph. This content model provides that an optional paragraph title, if used, must precede the primary text or body of a paragraph. The paragraph title must immediately precede the paragraph for which it is the title.
Parameter entity for the content model of a paragraph group. This content model provides that an optional paragraph group title, if used, must immediately precede either one or more first-level paragraph subgroup(s) or, alternatively, one or more combinations of an optional <paragraphTitle/> element immediately followed by a <paragraph/> element. An author must choose whether to use paragraph subgroups or simply to use paragraphs.
Parameter entity for the date and time content model. The date and time elements are used for marking up date and time information in a court document. Placing these elements together in a parameter entity makes it easier to reuse them as a group without an additional hierarchical container element such as the <dateTime/> element in the Court Filing 1.1 DTD.
In paper court documents, date information is expressed in a variety of ways, such as numerical values in mm/dd/yy, dd-mm-yy, or similar formats. Dates also may be spelled out in text. For purposes of this standard, authors can use the <date/> element to mark up date information as a text string in whatever format they desire. However, to make date information consistently machine readable and available to applications, dates must also be expressed as numbers within the required "date" attribute. To provide consistency and in keeping with the Court Filing 1.1 DTD, date and time information in the required attributes must follow the standards set by ISO 8601 (the ISO standard for numerical date/time interchange formats). Specifically, date information in the "date" attribute must be expressed numerically using the Gregorian Calendar and the form ccyy[-mm[-dd]]. All components shall be zero-padded to two digits and should be hyphenated -- for example <date date=" 2002-05-31">May 1, 2002</date> .
Similarly, time information in the required "time" attribute of the <time/> element must be expressed in Coordinated Universal Time (UTC), using the form hh[:mm[:ss[:ttt]]]Z. For example, <time time = "22:04:38.015Z">10:04:38 pm</time> represents thirty-eight and 15 thousands seconds after 10:04 PM. A Z shall be appended to the end. ISO 8601 uses this convention to express times in UTC. All components must be zero-padded to two digits.
Parameter entity for the content model for the name of a person. This content model requires authors to choose whether to mark up the full name of a person optionally followed by alias names, the person's alias name alone, or the person's last name (together with separate first and middle names, name prefixes, suffixes, aliases, and nicknames, which are optional) depending on the degree of detail desired. In requiring authors to provide at least one form of a person's name, this content model differs from, but does not collide with, the comparable content model of the <personName/> element in the Court Filing 1.1 DTD which makes all elements of a person's name optional. Placing these elements in a parameter entity simplifies the DTD by eliminating the need for additional hierarchical container elements such as the <name/> and <personName/> elements in the Court Filing 1.1 DTD.
Parameter entity for the content model for organization names. This content model requires authors to choose whether to provide the organization's name optionally followed by the name of a division (or department), and allows the optional choice of an alias name, acronym, or abbreviated name. Alternatively it also permits authors to mark up just a single abbreviated, acronym or alias name for the organization. In requiring authors to provide at least one form of an organization's name, this content model differs from the comparable content model of the <organizationID/> in the Court Filing 1.1 DTD which contains different child elements and makes all of them optional. Placing these elements in a parameter entity simplifies the DTD by eliminating the need for additional hierarchical container elements such as the <name/> , <entity/> and <organizationID/> elements in the Court Filing 1.1 DTD.
Parameter entity for the role content model. This content model permits authors to mark up text describing the roles of a person or organization and optionally allows a reference to associated persons or organizations. This content model is identical to the content model of the <role/> container element in the Court Filing 1.1 DTD.
Parameter entity for contact information for a person or organization. This content model allows authors the options of providing multiple postal addresses, phone and fax numbers, email addresses, and uri addresses. If contact information is provided, the various items must be given in the sequence listed. This content model is similar to, but differs somewhat from, the organization of elements used in the <actor/> element in the Court Filing 1.1 DTD for describing contact information. For one thing, this parameter entity groups together and "modularizes" elements describing contact information. Additionally, it includes elements for full telephone or full fax numbers as well as a <uri/> element, which are not present in the comparable content model in the Court Filing 1.1 DTD.
Parameter entity for identification information for a person. This content model allows authors optionally to mark up multiple identification numbers for a person, to provide either a person's birth date or age, or to include multiple text comments identifying or uniquely describing a person. Elements in this parameter entity are derived from elements in the <personDescription/> element in the Court Filing 1.1 DTD. However, for purposes of simplifying this DTD, none of the elements from the Court Filing 1.1 DTD for marking up the physical characteristics of a person are included.
Parameter entity for identification information for an organization. This content model allows authors optionally to mark up multiple identification numbers for or to include multiple text comments identifying or uniquely describing an organization. This parameter entity is based on the %personIdentification.content; parameter entity. It provides consistency in the content models used to describe identification information for persons and organizations.
Parameter entity for the postal address content model. This content model requires authors to choose whether to mark up detailed address information or to provide only a full address. If detailed address information is provided, each of the individual items is optional, but when used they must be given in the sequence listed. The content model of this parameter entity is virtually identical to the content model of the <postalAddress/> container element in the Court Filing 1.1 DTD, except that the <addressFull/> element name has been changed to <fullAddress/> for greater consistency with other similarly named elements in this DTD.
Parameter entity for the document metadata content model. This parameter entity holds elements to describe metadata about a court document that may be used by document management applications. Most of the elements in the document metadata parameter entity are based closely on the version 1.1 Dublin Core Metadata Element Set for describing metadata (see http://dublincore.org/documents/dces/ for details). An author must provide information for the <dateTimeCreated/> , <documentType/> , <creator/> , <submitter/> , and <format/> elements. The remaining elements are optional. Document metadata provided must be given in the sequence of the listed elements. The Court Filing 1.1 DTD does not contain a comparable content model for document metadata.
The <documentTitle/> element is optional in this content model, and it is a required element in the content model for the <caseMetadata/> element. If used in the <documentMetadata/> element, the contents must be identical to those of the <documentTitle/> element in <caseMetadata/> in order to avoid providing two different document titles for the same document.
Parameter entity for the content model of the tribunal in which a case or proceeding is pending. An author must choose whether the tribunal is a court or an agency.
Parameter entity for case metadata regarding the case in which the document is filed or served. Metadata about the case in which a court document is filed customarily appears in the caption at the beginning of a paper court document. Information identifying the tribunal (court or agency) in which the case is pending must be provided. The <fullCaseNumber/> and <caseTitle/> elements are optional. The <documetTitle/> element is required, and also is an optional element in the content model for document metadata.
Additionally, multiple <relatedCase/> elements may be included to describe information about related cases that have been consolidated, transferred, appealed, etc. The content model declared in this parameter entity is somewhat comparable to, but simpler than, the content models in the <caseInformation/> and <courtInformation/> container elements in the Court Filing 1.1 DTD. Thus, this parameter entity has been given a different name.
Parameter entity for the contents of a paragraph. The <paragraph/> element is the basic container of text information in the body of a court document and serves as the basic container for text expressing a thought or argument of an author. It has a mixed content model (i.e. it can hold text and subelements). The subelements that an author can use to mark up particular items of information within a paragraph are described in this parameter entity.
Parameter entity for describing the signers of a court document. This content model requires authors to provide signatory information for one or more signers optionally followed by a notarization. This information is not intended to serve as an electronic signature. Markup to describe information about electronic signatures used to sign an XML court document, including the type of electronic signature technology used, is provided in the <electronicSignature/> element.
Parameter entity for the content model for signatory information. This content model requires authors either to mark up one or more signature lines followed by information about one or more signatories or to mark up information about a signer followed by one or more signature lines depending on the sequence desired. These elements permit markup of the text appearing as a signature in paper court documents, but are not intended to affect the validity or invalidity of a digital signature electronically affixed to an XML court document.
Parameter entity for the content model for a notarization. This content model allows authors to mark up notarizations in affidavits, verifications, and similar court documents.
Parameter entity for the content model of a certificate of service. A certificate of service must contain one or more paragraphs (each of which may be optionally preceded by a paragraph heading), the date (and time, if desired) the document was served, and information about the signer of the certificate of service. The information must be provided in the sequence described.
Parameter entity for attributes of elements used for marking up text content in the body of a court document. Each of these attributes is optional, but authors may use any or all of them to provide a more detailed description of a particular item of content in the body of a court document, such as a paragraph group, paragraph, subparagraph, phrase, or list. The "label" attribute can contain a label, such as a number or letter designation, for the content item. The "type" attribute can contain a description of the category, genre, or nature of the item of content. The "subject" attribute can contain comma-separated keywords or key phrases describing the topics addressed in the content item. The "language" attribute describes the language of the content item using a two-letter language code (taken from the ISO 639 standard) and can be used to identify phrases, paragraphs, or other content items of a different language. The "privacy" attribute is an enumerated attribute indicating whether the content item should be sealed or redacted.
Parameter entity for the common attributes defined in the Court Filing 1.1 DTD for use with certain data elements common to law, safety, and justice applications. Because some elements in this DTD are data elements incorporated from the Court Filing 1.1 DTD, these common attributes also are included in this DTD for closer compatibility. This approach provides that elements appearing in both DTD's will have the same content models.
As described in the Court Filing 1.1 standard, "id" provides a means to identify a specific element in an XML document; "type" provides a means to describe the type of information being provided, "status" provides a place to describe the status of this information, "referenceDate" identifies the date on which the status was known to be accurate, and "codeSource," "codeValue," and "codeLiteral" are used to identify the appropriate code source (usually a formal standard), along with both the coded and literal forms of the data.
Parameter entity for attributes from the W3C's XML Linking Language (XLink) Version 1.0 Recommendation used to create an XML linking element. The default attribute values are for a simple XML link. The XLink attributes are used with the <link/> and <image/> elements in the Court Document 1.1 DTD. The xlink:type attribute describes the type of link -- the default is 'simple.' The required xlink:href attribute contains the URI for the linked resource. The optional xlink:role and xlink:title attributes contain information about the role and title of the target resource. The xlink:show attribute contains information for displaying the linked resource when the link is activated, such as by replacing the contents of the current window. The default value is 'replace.' The xlink:actuate attribute suggests when the link should be activated, such as only after a specific user request.
Parameter entity for the U.S. Postal Service (USPS) abbreviations for U.S. states. Postal abbreviations are declared in the DTD so that authors do not have to incorporate them from a separate source and to avoid potential problems from the use of inconsistent abbreviations.
The elements and attributes in the Court Document 1.1 DTD are declared and organized in the following groups: common elements used throughout a court document to describe the names, contact information, and roles of the participants in a legal proceeding (e.g. attorneys, judicial officers, witnesses, parties, etc.); elements for describing document metadata; elements for describing case metadata (e.g. information usually found in the captions of paper court documents); elements for marking up the textual content of the body of a court document; elements for describing information about the signer(s) of a court document; elements for marking up a certificate of service; and elements for describing attachments. An optional element is also included for electronic signature information. An alphabetical list of the elements declared in the Court Document 1.1 DTD is included as Appendix B .
The Court Document 1.1 DTD contains a group of "common" elements for describing name, contact, role, date and time, and XML linking information. Most of these common elements describe information about the people and organizations typically involved in lawsuits or administrative hearings, such as parties, attorneys, judicial officers, law enforcement officers, witnesses, and the like. Participants in a legal proceeding customarily are referred to and thought of in terms of their general roles in a proceeding (e.g. as a party, an attorney, a witness, and so forth). As described elsewhere in more detail, the Court Document 1.1 DTD includes separate elements for describing information about these and other participants in legal proceedings with the goal of making the DTD more intuitive, and it uses "common" elements and content models consistently within those elements to describe name, contact, and role information. In taking this approach, the Court Document 1.1 DTD differs from the Court Filing 1.1 DTD, which uses only a single, generic <actor/> element for a comparable purpose.
Additionally, the content model for the <actor/> element in the Court Filing 1.1 DTD contains several dozen XML elements for describing a wide range of information about both the people and the organizations involved in a case. A comprehensive set of elements is important for promoting data interchange using XML, but there is less need for a comprehensive set of elements to markup the more limited information about people or organizations typically appearing in the documents actually filed or served in a lawsuit or administrative proceeding. Thus, the Court Document 1.1 DTD seeks simplification by reducing both the number of "common" elements used for describing name, contact, and role information and the choices required to mark up such information.
However, many of the elements used in the Court Filing 1.1 DTD to describe name, contact, role, and other information can easily be used to mark up the same information in XML court documents. Consequently, for consistency the Court Document 1.1 DTD incorporates from the Court Filing 1.1 <actor/> element many "horizontal" common elements and content models for describing the names, contact information, and roles of various participants. The Court Document 1.1 DTD uses a smaller set of common elements to describe such information and organizes them to promote ease of learning and ease of use. As previously noted, it uses these "common" elements to form substantially similar and consistent content models within more descriptive "role" elements describing the various participants in a legal proceeding, such as <attorney/> , <party/> , <witness/> , or <organization> .
fullName contains the entire, or complete name of a person, including any prefix or suffix. It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
aliasName contains the alias of a person or organization. It is not included in the Court Filing 1.1 DTD. In addition to the %common.attributes; , the "aliasFor" attribute is a reference to the "id" attribute value of the party, person, or organization using the alias. The "aliasType" attribute is required to indicate the type of the alias name.
nickName contains the nickname of a person. It is not included in the Court Filing 1.1 DTD.
namePrefix contains any formal prefix that is used with a person's name, e.g., "The Honorable", "Mr.", "Ms.". It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
firstName contains the first, or given, name of a person. It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
middleName contains a person's middle name, initials, or multiple initials. Each of the names of a person between their first and last names are described by this element. It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
lastName contains the last, or family, name of a person. It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
nameSuffix contains a suffix to a person's name, such as "Jr.", "PhD", or "III". It also takes the optional common attributes -- id , type , status , referenceDate , codeSource , codeValue , and codeLiteral . It is incorporated from the Court Filing 1.1 DTD.
organizationName contains an organization's full name. It is based on the <entityName/> element in the Court Filing 1.1 DTD.
organizationUnit contains the name of a division or department within an organization. It is not included in the Court Filing 1.1 DTD.
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.
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.
postalAddress contains the % postalAddress.content parameter entity, which in turn contains a content model for describing a postal location to which paper mail can be directed. This content model is based on the <postalAddress/> element in the Court Filing 1.1 DTD and makes its child elements optional. However, it includes an additional enumerated attribute "addressType" from which authors can indicate the type of postal address information being provided. An enumerated attribute list of such choices is provided to standardize the descriptions of postal address types. The content model also requires authors to choose either the separate elements for an address or a full address, but not both. This difference, however, does not result in a collision with the content model used in the Court Filing 1.1 DTD for postal addresses, which allows either approach.
addressLine contains text address lines, and may include alternative text for locations that don't have a postal address system. <addressLine/> elements must be sequenced in the order they would appear on an address label. The attribute "type" may be used to identify the context of the address line, e.g., a firm name, a suite number, street, or post office box. It is incorporated from the Court Filing 1.1 DTD.
city contains the name of a city, town, or township. It is incorporated from the Court Filing 1.1 DTD.
county contains the name of a county. It is incorporated from the Court Filing 1.1 DTD.
state contains the name of a state or province. This content model is based on the <state/> element in the Court Filing 1.1 DTD, but includes an additional enumerated attribute "state" from which authors can select the USPS abbreviation for a U.S. state. An enumerated attribute list (as set out in the %state.codes parameter entity containing the USPS abbreviations for U.S. states) is provided for purposes of standardization. This element is substantially consistent with the Court Filing 1.1 DTD, which provides that USPS abbreviations are preferred for U.S. states, but uses the "codeValue" and "codeSource" attributes to indicate the value and source of the abbreviated codes instead of including them in an enumerated attribute.
postalCode contains the zip or postal code. It is incorporated from the Court Filing 1.1 DTD.
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.
fullAddress contains a complete address. The content model is identical to the content model of the <addressFull/> element in the Court Filing 1.1 DTD, but the element name has been changed for greater consistency with similarly named elements in this DTD. The ISO 3166 abbreviations for country names must be used if the country name is abbreviated.
telephone contains the information for a telephone number. It is incorporated from the Court Filing 1.1 DTD.
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.
telephoneCountryCode contains the country code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD.
telephoneCityCode contains the city code for an international telephone number. It is incorporated from the Court Filing 1.1 DTD.
areaCode contains the area code for a telephone number. It is incorporated from the Court Filing 1.1 DTD.
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.
telephoneSuffix contains the suffix, such as an extension, for a telephone number. It is incorporated from the Court Filing 1.1 DTD.
fullTelephone contains a complete telephone number. It includes an enumerated attribute "telephoneType" from which authors can indicate the type of telephone information being provided. An enumerated attribute list of such choices is provided to standardize the descriptions of telephone types. It is not included in the Court Filing 1.1 DTD.
fax contains a fax telephone number. It is incorporated from the Court Filing 1.1 DTD.
fullFax contains a complete fax telephone number. It includes an enumerated attribute "faxType" from which authors can indicate the type of fax telephone information being provided. An enumerated attribute list of such choices is provided to standardize the descriptions of fax telephone types. It is not included in the Court Filing 1.1 DTD.
email contains an email address. It is incorporated from the Court Filing 1.1 DTD, but includes an enumerated attribute "emailType" from which authors can indicate the type of email address being provided. An enumerated attribute list of such choices is provided to standardize the descriptions of email address types.
uri contains either a Universal Resource Identifier (URI) or a Universal Resource Locator (URL). It is incorporated from the Court Filing 1.1 DTD.
roleName contains the name of the role taken by a person or organization. It is incorporated from the Court Filing 1.1 DTD.
roleWith contains a description of the person or organization with which a relationship exists. It also has an optional "actorID" attribute which can point to the "id" attribute of other person or organization elements to indicate a relationship with them. For example, an attorney/client relationship or a relationship between a person and an organization can be described in this way. This element is based on the <roleWith/> element from the Court Filing 1.1 DTD.
date contains a text string describing a date. It is incorporated from the Court Filing 1.1 DTD, but includes two additional attributes. It includes a required attribute "date" for providing date information in ISO 8601 number format (e.g. 2002-05-31) as noted in the description of the % dateTime entity. It also includes the optional attribute "dateType" to contain further information describing the category of date information provided.
time contains a text string describing a time. It is incorporated from the Court Filing 1.1 DTD, but includes an additional required attribute "time" for providing time information in ISO 8601 number format as noted in the description of the % dateTime entity.
link contains the information to create an XML link. It uses the global attributes from the XLink namespace for compatibility with the W3C's XML Linking Language (XLink) Version 1.0 Recommendation . The XLink global attributes used by the <link/> element are declared in the %xlink.attributes; parameter entity and the default attribute values are set to create a simple link identical to an HTML link. For instance, a simple link to the Legal XML, Inc. home page would be <link xlink:type="simple" xlink:href="http://www.legalxml.org" xlink:title="Legal XML, Inc." xlink:show="replace" xlink:actuate="onRequest">Legal XML</link>. Although XLink global attributes can be used to make any element a linking element, they are used only by the <link/> and <image/> elements in this DTD.
image is an empty element for an image link using the global attributes from the XLink namespace for compatability with the W3C's XML Linking Language (XLink) Version 1.0 Recommendation . The fixed attribute values of the global XLink attributes create a simple link for embedding an image and thus are different from the default attribute values declared in the %xlink.attributes; parameter entity. Although XLink global attributes can be used to make any element a linking element, they are used only by the <link/> and <image/> elements in this DTD.
The Court Document 1.1 DTD classifies information about those typically involved or mentioned in court documents in two ways. First, it defines two elements, <person/> and <organization/> , to reflect the general distinction between human beings on the one hand and corporations, partnerships, associations, and similar inanimate legal entities on the other. Information about people is different in some respects from information about organizations, particularly with respect to name information, and the content models for these two elements reflect that difference. This approach is fundamentally different from the approach taken by the Court Filing 1.1 DTD, which uses only a single <actor/> element to contain information about both people and organizations.
Second, to make the DTD more intuitive, the Court Document 1.1 DTD defines separate elements describing the particular roles most frequently taken by those involved in a lawsuit or administrative proceeding. The names of the "role" elements in this DTD reflect the classifications that attorneys, judges, clerks, and others who regularly work with court documents typically use for those involved in a court or administrative proceeding. In this respect, the Court Document 1.1 DTD attempts to incorporate element names that are intuitive and meaningful to those who typically will be authoring XML court documents. This approach also makes it possible to more predictably and less ambiguously describe the nature of a particular person's or organization's involvement in a legal proceeding.
Six of the "role-specific" elements in the Court Document 1.1 DTD -- <attorney/> , <judicialOfficer/> , <notary/> , <administrativeOfficer/> , <enforcementOfficer/> , and <witness/> -- are intended to apply only to people. Consequently, each of these elements contains the same parameter entities, child elements, attributes, and content models as the more generic <person/> element. Two other "role" elements, <party/> and <victim/> , can refer either to human beings or to organizations. Thus, those two "role" elements contain child elements and content models for describing information applicable either to people or to organizations.
person contains the name, contact, identification, and specific role information for a person. It uses the content models from the %personName.content; parameter entity, %contact.content; parameter entity, <personIdentification/> element, and %role.content; parameter entity. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of a person; all other information is optional. This content model is loosely based on the content model of the <actor/> element in the Court Filing 1.1 DTD.
The <person/> element has almost all the attributes of the <actor/> element in the Court Filing 1.1 DTD. The optional "id" attribute contains a unique identifier for the person. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <person/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about a <person/> is sealed or redacted.
personIdentification contains elements to describe information uniquely identifying a person, such as personal id numbers, date of birth or age, or similar information. It uses the content models declared in the %personIdentification.content; parameter entity. The content model is loosely based on the <personDescription/> element in the Court Filing 1.1 DTD, but elements for describing physical characteristics and other personal information are not included to simplify this content model.
personalIDNumber contains an identification number assigned by various agencies and organizations for a person. It is incorporated from the Court Filing 1.1 DTD. The "type" attribute identifies the category of ID number assigned, e.g., "social security", "driver's license". This element has an additional attribute, "issuingAuthority" , which contains the name of the issuing organization or state issuing the identification number.
birthDate contains a text string giving the date of birth of a person. It is incorporated from the Court Filing 1.1 DTD, but the required "date" attribute has been added for providing date information in ISO 8601 number format.
age contains the age of a person. It is not included in the Court Filing 1.1 DTD.
comment contains the text of a comment. It is incorporated from the Court Filing 1.1 DTD.
attorney contains the name, contact, identification, and role information for an attorney. It uses the content models from the % personName.content ; parameter entity, the % contact.content ; parameter entity, the <barNumber/> element, the <personIdentification/> element, and the % role.content ; parameter entity. Information about the name of an attorney must be provided; all other information is optional. This content model is nearly identical to the content model for the <person/> element -- only the <barNumber/> element has been added. This element has the same attributes as the <person/> element.
barNumber contains the bar number for an attorney. It is incorporated from the Court Filing 1.1 DTD, although the attributes "issuingAuthority" , "yearAdmitted" , and "barStatus" have been added. These attributes contain information describing the state bar issuing the bar number, the year the attorney was admitted to practice, and the status of the attorney's license. These attributes are based on elements appearing in the <barMembershipInformation/> element of the Court Filing 1.1 DTD, but have been changed to attributes to simplify this DTD.
judicialOfficer contains the name, contact, identification, and role information for a judge, clerk of court, magistrate, or similar judicial official. It uses the same content models as the <person/> element. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of the judicial officer; all other information is optional. The <judicialOfficer/> element also has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the judicial officer. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <judicialOfficer/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about a <judicialOfficer/> is sealed or redacted.
notary contains the name, contact, identification, and role information for a notary public. It uses the same content models as the <person/> element. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of the notary; all other information is optional. The <notary/> element also has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the notary. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <notary/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about a <notary/> is sealed or redacted.
administrativeOfficer contains the name, contact, identification, and role information for an administative law judge, hearing officer, board member or similar administrative official. It uses the same content models as the <person/> element. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of the administrative officer; all other information is optional. The <administrativeOfficer/> element also has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the administrative officer. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <administrativeOfficer/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about an <administrativeOfficer/> is sealed or redacted.
enforcementOfficer contains the name, contact, identification, and role information for a police officer, sheriff, deputy, detective, or similar law enforcement official. It uses the same content models as the <person/> element. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of the enforcement officer; all other information is optional. The <enforcementOfficer/> element also has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the enforcement officer. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <enforcementOfficer/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about an <enforcementOfficer/> is sealed or redacted.
witness contains the name, contact, identification, and role information for a witness. It uses the same content models as the <person/> element. The %personName.content; parameter entity requires authors to provide the full name, alias name, or last name of the witness; all other information is optional. The <witness/> element also has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the witness. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <witness/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about an <witness/> is sealed or redacted.
organization contains the name, contact, identification, and role information for an organization, such as a corporation, association, partnership, or similar legal entity. It uses substantially the same content models as the <person/> element. However, it uses the %organizationName.content; parameter entity instead of the %personName.content; parameter entity for name information and the <organizationIdentification/> element instead of the <personIdentification/> element.
The <organization/> element has the same attributes as the <person/> element. The optional "id" attribute contains a unique identifier for the organization. The optional "reference" attribute contains the value of the "id" attribute of a fully defined <organization/> element appearing elsewhere in the document. The "privacy" attribute can be used to indicate whether information about an <organization/> is sealed or redacted.
organizationIdentification contains elements to describe information uniquely identifying an organization. It uses the content models declared in the %organizationIdentification.content; parameter entity. The content model is based on the <personIdentification/> element and provides consistency in the content models used to describe identification information for persons and organizations.
organizationIDNumber contains identifiers for an organization. The "type attribute identifies the category of ID number assigned. This element has an additional attribute, "issuingAuthority" , which contains the name of the authority issuing the identification number.
victim contains information about a person or organization that is the victim of a crime. It contains either a single <person/> or <organization/> child element, and thus incorporates the content models used by those elements. It has an optional "id" attribute.
party contains information about a person or organization that is a party in the proceeding. It contains either a single <person/> or <organization/> child element (and thus incorporates the content models used by those elements). Information about a party's attorney(s) is optionally contained in the <party/> element to reflect the attorney's relationship with the party.
The <party/> element has a required "partyType" attribute to describe the particular type of party, e.g. "Paintiff," "Respondent," "Third-Party Defendant," etc. A specific description of the particular role of a party also can be contained in the <roleName/> element of the <person/> or <organization/> elements. The <party/> element has an optional "id" attribute.
The Court Document 1.1 DTD uses the element <legal/> , a generic tag preceding all legal-related XML, as the root element. The <legal/> element can contain one or more XML court documents. The information in each XML court document is organized into six basic parts -- document metadata, case metadata, the document body, signature information, the certificate or proof of service, and attachments. The document metadata, case metadata, and document body portions of an XML court document must always be present in order for an XML court document to be valid against this DTD, but the signature, proof of service, and attachment parts are optional. An optional <electronicSignature/> element is also provided for electronic signature information.
legal is the root element of an XML court document and contains one or more required <courtDocument/> elements. This generic tag precedes all legal related XML.
courtDocument holds the container elements for the contents of an XML court document. The <documentMetadata/> , <caseMetadata/> , and <documentBody/> elements must be present in the sequence stated. The <signers/> , <proofOfService/> , and <attachedItem/> elements are optional, but must appear in the sequence stated if used. It also contains an optional <electronicSignature/> element which describes information regarding the electronic signature used for electronically signing the court document(s). The <courtDocument/> element has a fixed "version" attribute specifying the version number as 1.1.
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.
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. The <creator/> , <submitter/> , <documentTitle/> , <documentType/> , <documentIdentifier/> , <dateTimeCreated/> , and <format/> elements are required. The <contributor/> , <description/> , <subject/> , <coverage/> , <language/> , <reference/> , and <documentStatus/> elements are optional.
documentIdentifier is a required element containing an unambiguous reference, typically a string or number conforming to an identification system, to the court document. The <documentIdentifier/> element is substantially similar to the Dublin Core "identifier" element.
dateTimeCreated is a required element containing the date and time associated with the creation or last modification of the court document. The <dateTimeCreated/> element is substantially similar to the Dublin Core "date" element and is based on the <creation/> element in the Court Filing 1.1 DTD. It contains the %dateTime.content; parameter entity.
documentTitle is an optional element containing the title or name given to the court document. It is optional in this content model, and it is a required element in the content model for <caseMetadata/> . If used in this element, the contents must be identical to the contents of the required <documentTitle/> element in <caseMetadata/> in order to avoid providing two different document titles for the same document. The <documentTitle/> element is substantially similar to the Dublin Core "title" element and is incorporated from the Court Filing 1.1 DTD.
documentStatus is an optional element containing a description of the status of the court document. The "draft" attribute indicates whether the court document is a draft or final version (the default enumerated attribute value is "draft"). The optional "privacy" enumerated attribute indicates whether the court document is sealed or redacted. The "specialHandling" attribute indicates whether special handling of the court document is needed (the default enumerated attribute value is "yes"). If the <documentStatus/> element is not present in a court document, then the court document is presumed to be a final version which is not sealed or redacted and which does not require any special handling.
documentType is a required element containing a description of the nature, category, or genre of the content of the court document. The <documentType/> element is substantially similar to the Dublin Core "type" element and is incorporated from the Court Filing 1.1 DTD. For consistency with the Court Filing 1.1 DTD, it takes an optional "documentCode" attribute which can contain a specific code describing the type of court document.
creator is a required element containing either a single <person/> or <organization/> element and describes the person or organization primarily responsible for making the content of the court document.
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.
submitter is a required element containing information regarding the party, attorney, judicial officer, administrative officer, enforcement officer, notary, court, or agency responsible for making the court document available by serving it or submitting it for filing. The <submitter/> element is substantially similar to the Dublin Core "publisher" element.
format is a required element containing the media type, usually the MIME type (text/xml), of the court document.
description is an optional element containing an abstract or text summary of the contents of the court document.
subject is an optional element containing comma-separated keywords or key phrases describing the topic(s) addressed in the court document.
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.
language is an optional element containing a description of the language of the court document. The description of the language must follow RFC 1766 , which includes a two-letter language code from the ISO 639-1 standard followed optionally, by a two-letter country code from the ISO 3166 standard. For example, 'en' for English, 'fr' for French, or 'en-uk' for English used in the United Kingdom.
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.
Information typically found in captions of court documents, such as the name and location of the tribunal in which the case is pending, the case number, and the names of the parties, is contained in the <caseMetadata/> element. The content model for this element is described in the %caseMetadata.content; parameter entity.
caseMetadata contains the elements and content model for describing metadata about the case or proceeding in which the court document is being filed or served. Its child elements and content model are described in the %caseMetadata.content; parameter entity. The %tribunal; parameter entity requires an author to identify the tribunal in which the document is being filed as either a court or administrative agency. The <fullCaseNumber/> and <caseTitle/> elements are optional, but may occur only once. The optional <relatedCase/> element may occur multiple times.
The <caseMetadata/> element has an optional "caseType" attribute, which can be used to describe the case type. This attribute may contain the case types described in the Court Filing 1.1 DTD (e.g. civil, domesticRelations, probate, smallClaims, etc.) or additional case types not listed in the Court Filing 1.1 DTD (e.g. arbitration, industrialCommission, etc.).
court contains the elements and content model to describe the name of the court in which the case is pending, its venue or more detailed contact information, and information regarding the judicial officers involved in the case. This content model requires authors to provide the court's name (optionally followed by a division, district, or circuit name or an abbreviated name) or just an abbreviated name of the court. It also requires authors to provide either the venue of the court (city or county and state) or to provide more detailed contact information (using the content model of the %contact.content; parameter entity previously described). Information about the judicial officer(s) involved is optionally contained in the <court/> element to reflect their relationship with the court. The <court/> element also has an optional "courtType" element to describe the general category or level of the court.
< !ATTLIST court courtType CDATA #IMPLIED >
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.
courtDivision is an optional element containing the name of the division of the court in which the case is pending.
courtDistrict is an optional element containing the name of the district of the court in which the case is pending.
courtCircuit is an optional element containing the name of the circuit of the court in which the case is pending.
courtDepartment is an optional element containing the name of the department of the court in which the case is pending.
venue contains the content model for describing a location optionally using either the name of the city or county and the state. The <state/> element is required. It describes the general location of the court.
agency contains the elements and content model to describe the name of the agency in which the proceeding is pending, its venue or more detailed contact information, and information regarding the administrative officers involved in the proceeding. This content model requires authors to provide the agency's name (optionally followed by an office, bureau, department, or board name or either an abbreviated name or agency acronym) or just an abbreviated name or acronym of the agency. It also requires authors to provide either the venue of the agency (city or county and state) or to provide more detailed contact information (using the content model of the %contact.content; parameter entity previously described). Information about the administrative officer(s) involved is optionally contained in the <agency/> element to reflect their relationship with the agency. The <agency/> element also has an optional "agencyType" element to describe the general category or level of the agency.
agencyName is a required element containing the name of the agency in which the proceeding is pending.
agencyAcronym is an optional element containing any common acronym by which the agency is known.
agencyOffice is an optional element containing the name of the office of the agency in which the proceeding is pending.
agencyBureau is an optional element containing the name of the bureau of the agency in which the proceeding is pending.
agencyDepartment is an optional element containing the name of the department of the agency in which the proceeding is pending.
agencyBoard is an optional element containing the name of the board of the agency in which the proceeding is pending.
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.
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.).
fullCaseTitle contains the full case title of the case or proceeding.
inRem contains the title for an "in rem" case or proceeding that does not involve people or organizations as parties.
partyGroup contains one or more <party/> elements. Information about the attorney(s) for the party group also is optionally contained within the <partyGroup/> element to reflect the attorney's relationship with the group. The <partyGroup/> element has a required "partyType" attribute to describe the particular type of party, e.g. "Paintiffs," "Respondents," "Third-Party Defendants," etc. It also has an optional "id" attribute.
vs is an element used to separate the <party/> or <partyGroup/> elements.
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.
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.
The Court Document 1.1 DTD organizes the text contents of the body of an XML court document into a structural hierarchy of paragraph groups (i.e. sections), paragraph subgroups (i.e. subsections), paragraphs, and subparagraphs. Paragraph subgroups and subparagraphs extend to three levels, thus establishing a hierarchical structure that includes sub-sub-subsections and sub-sub-subparagraphs. The document body also contains a text-free <machineData/> element intended to hold data-containing elements specifically for use by machines and it contains the date the XML court document was submitted for filing.
Within paragraphs, the basic container of text content in the body of an XML court document, the Court Document 1.1 DTD allows the use of various elements to mark up footnotes, lists, citations, phrases, quotations, and similar items of text content. Further, it permits the use of the "role" elements, such as the <person/> or <party/> elements, within paragraphs.
The Court Document 1.1 DTD also allows the optional use of a special element named <addIn/> within paragraphs. The <addIn/> element has an ANY content model, which means that it can contain parsed text or any of the other elements declared in the Court Document 1.1 DTD. This makes it a convenient mechanism for easily customizing and extending the DTD by adding in new markup. New elements or parameter entities can be added to the DTD and then used within an <addIn/> element in the paragraphs of an XML court document. The ANY content model can be useful in the early stages of DTD development because it completely opens up the element content models in the DTD. As a DTD matures, however, the use of ANY can become a detriment, because new markup may be meaningless to applications created to process existing XML documents. Since the effort to develop a standard DTD for XML court documents is at an early stage, the flexibility afforded by the ANY content model of the <addIn/> element is presumably more beneficial than detrimental.
documentBody contains the elements and content models for marking up the text contents of the body of a court document. It must contain one or more <paragraphGroup/> elements or one or more combinations of an optional <paragraphTitle/> element immediately followed by a <paragraph/> element. These elements are followed by a single required <dateTimeSigned/> element and an optional <machineData/> element.
paragraphGroup contains the content model described in the %paragraphGroup.model; parameter entity. This element must contain either one or more paragraphs or first-level subgroup(s) of paragraphs (i.e. a subsection). It also contains an optional <paragraphGroupTitle/> element, which must precede any other elements if it is used.
The <paragraphGroup/> element has a required "id" attribute to hold a unique identifier. It also takes the optional content attributes defined in the %content.attributes; parameter entity. The "label" attribute can contain a label, such as a number or letter designation, for the paragraph group. The "type" attribute can describe the general category or nature of the paragraph group's contents, and the "subject" attribute can contain comma-separated keywords or key phrases describing the concepts discussed. The "language" attribute describes the language of the text using a two-letter ISO 639 language code. The "privacy" attribute indicates whether the paragraph group should be sealed or redacted.
paragraphGroupTitle contains the title of a paragraph group or subgroup.
paragraphSubgroup1 describes a first-level subgroup of paragraphs and must contain either one or more paragraphs or second-level subgroup(s) of paragraphs (i.e. a sub-subsection). It also contains an optional <paragraphGroupTitle/> element, which must precede any of the other elements. The <paragraphSubgroup1/> element takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
paragraphSubgroup2 must contain either one or more paragraphs or third-level subgroup(s) of paragraphs (i.e. a sub-sub-subsection). It also contains an optional <paragraphGroupTitle/> element. The <paragraphSubgroup2/> element takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
paragraphSubgroup3 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" .
paragraph contains text expressing a thought, concept, or argument of an author. It has a mixed content model (i.e. it can hold text and subelements). The subelements that an author can optionally use to mark up information within a paragraph are described primarily in the %paragraph.content; parameter entity. These optional subelements include any of the "role" elements describing those involved in the case (e.g. <party/> , <attorney/> , <person/> , etc.), the <addIn/> element discussed previously, and a variety of elements describing particular items of text content that frequently appear in the paragraphs of court documents, such as footnotes, citations, phrases, quotations, lists, links, dates, and addresses or venues. An <annotation/> element is provided to contain an author's notes. Additionally, a <paragraphTitle/> element and an element for first-level subparagraphs ( <subparagraph1/> ) also are provided.
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.
paragraphTitle contains the title of a paragraph.
subparagraph1 contains a first level subparagraph. It has a mixed content model (i.e. it can hold text and subelements) like the <paragraph/> element. It contains the subelements described in the %paragraph.content; parameter entity along with a <subparagraphTitle/> element and second-level subparagraphs ( <subparagraph2/> ). The <subparagraph1/> element also takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
subparagraphTitle contains the title of a subparagraph.
subparagraph2 contains a second level subparagraph (i.e. a sub-subparagraph). It has a mixed content model (i.e. it can hold text and subelements) like the <paragraph/> element. It contains the subelements described in the %paragraph.content; parameter entity along with a <subparagraphTitle/> element and third-level subparagraphs ( <subparagraph3/> ). The <subparagraph2/> element also takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
subparagraph3 contains a third level subparagraph (i.e. a sub-sub-subparagraph). It has a mixed content model (i.e. it can hold text and subelements) like the <paragraph/> element. It contains the subelements described in the %paragraph.content; parameter entity along with a <subparagraphTitle/> element. The <subparagraph3/> element also takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
addIn is a special element having an ANY content model. It can contain parsed text or any of the other elements declared in the Court Document 1.1 DTD. It is provided as a convenient mechanism for easily customizing and extending the DTD by adding in new markup. New elements or parameter entities can be added to the DTD and then used within an <addIn/> element in the paragraphs of an XML court document. However, the <addIn/> element should be used with care, because new markup added by means of an <addIn/> element may be meaningless to applications created to process existing XML court documents.
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" .
keyword contains a single word or term having special significance or meaning. It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . It also has additional optional attributes that can be used to more specifically define the particular meaning of the keyword. The "description" attribute contains a description or account of the content of the keyword. The <keyword/> element also has an optional "id" attribute.
literal contains some specific piece of text or other data taken literally. It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . It also has a "description" attribute, which contains a description or account of the content of the literal text or other data. The <literal/> element has an optional "id" attribute.
phrase contains a short span of text having special significance or meaning. It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . It also has additional optional attributes that can be used to more specifically define the particular meaning of the phrase. The "description" attribute contains a description or account of the content of the phrase. The "source" attribute refers to a resource from which the phrase is derived. The <phrase/> element also has an optional "id" attribute.
quotation contains a quotation from another document or resource. It has mixed content and can contain <simpleCite/> , <keyword/> , <literal/> , <phrase/> , <date/> , or <link/> elements as well as parsed text.
It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . It also has a "description" attribute, which contains a description or account of the content of the quotation. The "source" attribute refers to the resource from which the quotation is taken. The <quotation/> element has an optional "id" attribute.
footnote contains a footnote. It must contain a <footnoteNumber/> element followed by a <footnoteBody/> element. It takes three of the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , and "subject" . It also has a "title" attribute and an optional "id" attribute.
footnoteNumber must contain the number of a footnote. It has no attributes.
footnoteBody contains the body of a footnote. It has mixed content and can contain <simpleCite/> , <keyword/> , <literal/> , <phrase/> , <quotation/> , <date/> , or <link/> elements as well as parsed text. It has no attributes.
list contains any sequence of items organized as a list. It must contain either one or more <listItem/> element(s) or another <list/> element. It is the only element in the Court Document 1.1 DTD having a recursive content model (i.e. a list can contain a list which can contain another list, etc.). It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . The "type" attribute may be used to describe whether the list is an ordered, unordered, or other type of list. The <list/> element has an optional "id" attribute.
listItem contains a single item in a list. It has mixed content and can contain <simpleCite/> , <keyword/> , <literal/> , <phrase/> , <quotation/> , <date/> , or <link/> elements as well as parsed text. It also can contain <person/> or <organization/> elements. It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" .
annotation contains an annotation by an author or editor regarding the contents of a paragraph. It has mixed content and can contain <simpleCite/> , <keyword/> , <literal/> , <phrase/> , <quotation/> , <date/> , or <link/> elements as well as parsed text.
It takes the optional content attributes defined in the %content.attributes; parameter entity -- "label" , "type" , "subject" , "language" , or "privacy" . It also has several additional attributes. The optional "id" attribute identifies the annotation. The optional "refersTo" attribute contains the values of the "id" attributes of other elements to which it points. The "creator" attribute identifies the annotation author, and the "description" attribute describes the contents of the annotation.
dateTimeSigned is a required element containing the date and time associated with the signing of the court document for service or filing. It contains the %dateTime.content; parameter entity to incorporate the <date/> and <time/> elements and it has no attributes.
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.
The elements and content models for marking up information about the signers of an XML court document are contained in the <signers/> element. These elements describe the text information that typically comprises the signature block of a paper court document. However, the <signers/> element is not intended to serve as an electronic signature of an XML court document. Electronic signature information is provided in the separate <electronicSignature/> element.
signers contains the content model described in the %signers.content; parameter entity. It is an optional element, but if used it must contain signatory information for one or more signers of the court document optionally followed by a notarization. It has no attributes.
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.
signatureLine contains a signature line for the text of a signature. It has no attributes.
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.
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.
notarySeal contains the notary's seal. It has no attributes.
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.
The elements and content models for marking up information for a certificate or proof of service of an XML court document are contained in the <proofOfService/> element. A certificate of service is required by the rules of legal procedure in most U.S. courts. It documents that the party filing or serving a court document has mailed or delivered (i.e. has served) a copy on the other parties. The content model for a certificate or proof of service is described in the %proofOfService.content; parameter entity. It requires authors to provide one or more paragraphs, followed by a required <dateTimeServed/> element indicating the date and, optionally the time, that the XML court document was served (which may be different from the date the XML court document itself was signed), and a required <signatory/> element to contain information about the signer of the certificate or proof of service.
proofOfService contains the content model described in the %proofOfService.content; parameter entity. It is an optional element, but if used it must contain one or more paragraphs followed by the date (and optionally the time) of service, and information about the signer of the certificate or proof of service. It has no attributes.
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.
Electronic attachments to court documents present complications. Frequently they will not be other XML documents. For example, an attachment to an XML court document may be a binary word processing file or digital photo instead of an XML court document. The Court Document 1.1 DTD follows an approach similar to the Court Filing 1.1 DTD, which assumes that attached items will be either base-64 encoded BLOBs or, alternatively, a <![CDATA[ (unparsed character data) section within the <attachedItemContent/> element or, when allowed by a court as a matter of local policy, a hyperlink.
attachedItem describes the content model for an attachment to the XML court document. It contains an optional <documentMetadata/> element, which contains elements for describing metadata about the attached item, followed by one or more <attachedItemContent/> elements. This content model is different from the content model used to describe attachments in the Court Filing 1.1 DTD and thus has a different element name.
To accomodate the variety of items that might be included as attachments, the Court Document 1.1 DTD follows an approach similar to the Court Filing 1.1 DTD. It assumes that attached items will be either base-64 encoded BLOBs or, alternatively, a <![CDATA[ (unparsed character data) section within the <attachedItemContent/> element or a hyperlink (when allowed by a court as a matter of local policy). Base-64 encoding removes the < and & characters and other XML delimiters recognized as such by an XML parser. The alternative, marking a section of text as CDATA, can be used for attachments that are XML documents since it in effect turns off the parser so that the presence of XML elements that are not declared in the XML Court Document 1.1 DTD will not trigger parsing errors.
attachedItemContent contains the contents of an attachment to the court document. The attachment may be a base-64 encoded BLOB (particularly useful when the document being filed is a binary file), or, alternatively, a <![CDATA[ (unparsed character data) section. The <attachedItemContent/> element uses attributes borrowed from the Court Filing 1.1 DTD. It has a required "mimeType" attribute to indicate how the contents of decoded PCDATA are to be interpreted (e.g., application/PDF). The optional "contentEncoding" attribute indicates the type of content encoding used and allows for future revisions. The "href" attribute specifies the location of a hyperlinked document.
The elements and content models used in the <electronicSignature/> element simply provide information by which applications can determine if, how, and whether an XML court documents being read, exchanged or accessed has been electronically signed, and if so, which electronic signature technologies have been used.
electronicSignature describes information by which an application can determine whether an XML court document has been electronically signed, and if so, the particular electronic signature technologies that have been used. The <dataIntegrity/> and <authentication/> elements are required, and the <digitalSignatureInformation/> element is optional.
dataIntegrity identifies the type of binding used for purposes of data integrity. It has a required "bindingType" enumerated attribute from which the specific type of bindng can be selected.
authentication contains information describing the means of authenticating an XML court document. The optional "userIdentification" and "password" attributes provide for authentication by means of a user id and password. The <authentication/> element has a required "autheticationType" enumerated attribute to indicate the type of authentication used.
digitalSignatureInformation has an ANY content model and is a placeholder for information regarding digital signatures. It is anticipated that the content model for this element will ultimately incorporate or mirror standard elements and attributes for XML digital signatures.
Work to develop standards for XML court documents is ongoing. This Court Document 1.1 proposed standard is based upon a Document Type Definition (DTD), but DTD's are currently being replaced by W3C XML schemas. XML schemas are a more robust way of defining XML elements and content models that avoid some of the limitations and difficulties of DTDs. Thus, it is anticipated that future efforts to establish a standard for XML court documents will include a proposed XML schema as well as refinements and updates to the Court Document DTD.
The general entities declared in the Court Document 1.1 DTD are derived from the corresponding ISO 8879 standard entity set as incorporated in the Simplified DocBook DTD v4.1.2.5. The general entities permit various characters such as the section, paragraph, currency, fractions, and other symbols and signs to be used within XML court documents. For instance, "& para;" (without whitespace) can be used in an XML court document for the paragraph symbol and "& sect;" (also without whitespace) can be used for the section symbol. The character entities are declared at the beginning of the DTD and then can be used at any point within an XML court document.
The general character entities in the Court Document 1.1 DTD are listed here.
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.
The sample XML court documents in this Appendix are for purposes of illustration only. The sample stylesheets also are solely for purposes of illustrating how stylesheets can be used to display the contents of XML court documents. As noted in the proposed Court Document 1.1 standard, if an inconsistency arises between an example document and the Court Document 1.1 DTD, the DTD shall control. The Court Document 1.1 standard also does not attempt to establish any standard stylesheets for displaying XML court documents -- the samples in this Appendix simply illustrate one way that the contents of XML documents can be transformed for display to human readers using a stylesheet. It is conceivable that courts may develop standard stylesheets for displaying XML court documents uniformly and the creation of more tailored and more fully developed stylesheets is expected..
The sample documents can be viewed in XSLT capabale web browsers on client machines. The Microsoft Internet Explorer 5.0 web browser or higher (assuming that the msxml3 or msxml4 XML parser and XSLT processor is installed) and the Mozilla 1.0 Release Candidate 3 web browser can display XML documents using XSLT stylesheets.
The sample XML court documents all are valid against the proposed Court Document 1.1 DTD. They include a variety of representative documents from both courts and agencies. To view the court document as raw XML, use the "View Source" feature of the web browser.