OASIS LegalXML Member Section XML Court Document 1.1 Candidate Specification

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

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

It further assumes that authors will create documents that communicate, explain, argue, clarify, and decide legal issues and concepts arising in a specific case, and that the contents of such documents are not likely to be readily reusable in other contexts or cases. This specification also assumes that the basic structures of ordinary grammar, the phrase and paragraph, as opposed to a comprehensive set of data elements, are the preferred containers for text expressing legal ideas and concepts in XML-tagged court documents. The specification strives for consistency and intuitiveness with respect to element and attribute names, favors parallel design of XML tags used for marking up similar content, and seeks to avoid requiring choices that might be confusing.

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

In contrast, structured markup languages like XML use named elements, not visual font changes, indentations, and the like, to indicate the structure and semantic meaning of the text in a document. The markup tags (rather than stylistic formatting) impart structure to the document. For example, the XML element <documentTitle/> indicates the text it contains is the title assigned to the document, but it says nothing about the font or spacing that should be used to display that text. Structured markup, however, makes it possible for software to interpret and process documents for many different purposes. Applications can reliably retrieve and process text information from structured documents in predictable, useful ways. For instance, it is possible to publish the contents of a structured document in a wide variety of formats, including HTML on a Web page, printouts to paper, Braille, or even audio, all of them using the very same source document.

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

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

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

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

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

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

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

The Court Document 1.1 DTD and the Legal XML Electronic Court Filing 1.1 DTD serve different though related purposes. The Court Filing 1.1 specification defines data elements needed for the electronic filing of various types of electronic documents by court case management systems. It provides a standard XML vocabulary to describe the data required for electronic court filing and the structure of those data elements, their attributes, and their relationships. It uses XML to promote data interchange with court filing management systems. However, it does not include information about the detailed content or structure of the pleading or other court document contained within the standardized XML envelope.

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

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

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

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

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

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

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

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

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

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

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

One way to handle this difficulty is by declaring two DTDs: one without XML namespaces and another one with XML namespaces. The Court Document 1.1 DTD does not adopt this solution and does not declare or use XML namespaces with its core elements and attributes (although it does use XML namespaces with elements incorporated from other domains, such as Xlink attributes based on the XML Linking Language (XLink) Version 1.0 Recommendation and elements from the W3C's XML-Signature Syntax and Processing Recommendation (2002-02-12) for XML digital signatures). When the use of an XML namespace with Court Document 1.1 XML elements or attributes is desired (for example with XML documents validated against an XML Schema rather than a DTD), the XML namespace URI "http://www.legalxml.org/ns/courtdocument11.dtd" must be used and the namespace prefix "cd:" might be used. For example, if an XML namespace is used with the XML elements and attributes defined in this DTD, the Court Document 1.1 element <courtDocument/> would become <cd:courtDocument xmlns:cd = "http://www.legalxml.org/ns/courtdocument11.dtd"/>.

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

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

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

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

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

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

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

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

The proposed XML Court Document 1.1 DTD uses parameter entities to declare standard content models for many of its elements and attributes. The use of parameter entities permits the elements and attributes to be organized within the DTD in a more modular way and also makes customizing and extending the DTD easier. Using parameter entities in a DTD makes it easier for DTD users to maintain, customize and extend the DTD without requiring that the DTD be entirely re-written. A new parameter entity "module" can be declared that contains the new elements or new content models. The new parameter entity can then be added to the DTD as an alternative to or replacement for the one affected by the changes or to make new elements or attributes available for use. Official modifications to the Court Document 1.1 DTD require action by the appropriate OASIS Legal XML Court Filing Technical Committee and would be reflected in updates distinguished by higher version numbers and/or issue dates.

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

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

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

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

<!ENTITY % person.ANY "">

<!ENTITY % organization.ANY "">

<!ENTITY % paragraph.ANY "">

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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