The California Administrative Office of the Courts ("CA AOC") initiated the Second Generation Electronic Filing Specifications ("2GEFS" or "Specifications") to facilitate the development and implementation of interoperable electronic filing solutions in the California courts. The Specifications include Court Filing 2.0, Court Policy 2.0, Request-Response 2.0, and CMS-API 2.0. The CA AOC commissioned and financed the development of the Specifications for application in California courts. Additionally, a number of private companies volunteered time and expertise to develop, implement, and test of the Specifications.

Section 1, 2GEFS Roadmap, is a roadmap of the 2GEFS Specifications. It includes a short summary of each Specification and explains how the Specifications relate to each other.

Section 2, Phase 1 and Phase 2 Overview, is a summary of the 2GEFS Phases 1 and 2. For each project phase, Section 2 provides a short summary of the project scope, timeline, deliverables, staff, and participants.

Section 3, Resources, outlines the project's expended resources. Resources are itemized in terms of human resource hours expended by CA AOC staff and consultants, by the Sacramento Superior Court's staff, and by service providers. Section 3 also includes a list of unaccounted resources that contributed to the success of the project.

Section 4, Court Filing 1.0 Legacy, compares the scope of the 2GEFS to its predecessor, Court Filing 1.0. Here you will find outlined the features of Court Filing 1.0 that were incorporated into the 2GEFS such as the concept of the Document BLOB (Binary Large Object) and the three levels of information envelopes. You will also find the important differences and improvements between the two specifications, the most important being the evolution from DTD to XML Schema.

Section 5, Court Filing 2.0 Lessons Learned, covers lessons learned about Court Filing 2.0 during the Sacramento implementation. Section 5 covers lessons learned about validation, including schema, programmatic and human validation. Section 5 also covers transmission of XML over HTTP, confirmations, envelope and header issues, the <xmlLegal> test suite, filing and confirmation statistics, implementation issues, data issues, and network architecture and security.

Section 6, Court Policy 2.0 Lessons Learned, explains lessons learned about Court Policy 2.0 during the Sacramento implementation. Section 6 explains the information that court employees need to collect to build a court policy and highlights information that is difficult to gather. Section 6 focuses on document types, roles, and generic types. It also focuses on unique identifiers for courts and divisions of court and how these identifiers relate to a court's organization.

Section 7, Request-Response 2.0 and CMS-API 2.0, states simply that resource constraints did not allow the Sacramento court to implement Request-Response or CMS-API.

Section 8, Suggestions for Future Projects, includes a list of resources existing in the current project that should be used in future projects and a list of resources that did not exist in the current project that would be helpful in future projects.

Appendix A, Definitions, includes definitions of important terms found in this document.

If you would like to join the 2GEFS community of courts and developers and gain access to the lessons learned document, please contact Christopher Smith at the California Administrative Office of the Courts at Christopher.Smith@jud.ca.gov.

2GEFS Lessons Learned Document

From August 2000 to November 2001, Georgia Courts Automation Commission and Georgia State E-CourT-Filingproject conducted an electronic court filing interoperability pilot project using Legal XML Court Filing 1.0 specification (Free). Lessons Learned I (Free), a document that explains the project, as well as a number of other resources including the project's document type definition are published on the E-CourT-Filingprojectwebsite.

Lessons Learned II (Free) is an update on Georgia Courts Automation Commission's Interoperability Pilot Project. This document also includes information about filing of Georgia Child Support and Juvenile electronic filings. An article titled "Georgia Courts Automation Commission: Juvenile and Child Support Electronic Filing Systems," (Free) in the "e-Filing Report" November, 2003 issue (Vol. 3, No. 10) published by Glasser Legalworks (http://www.legalwks.com/) summarizes the projects. Lessons Learned III (Free) is a more in-depth look at the juvenile and child support projects.

The E-CourT-Filingproject continued its electronic filing project in Douglas County Juvenile Court where XML juvenile documents are filed over the Internet into a case management system.

Live filings of XML documents wrapped in Court Filing XML 1.0 began in May 2002. From January 2003 until September 2003, approximately 900 juvenile complaints were filed from the Douglas County Sheriff's and Police Departments into the Douglas County Juvenile Court. The juvenile complaints are XML documents based on the <xmlLegal>Schema Framework.

The lessons learned documents as well as other project documentation are available on the E-CourT-Filingprojectwebsite. You will need a Georgia State password to access the documentation.

Most or all Court and Justice XML Specifications, such as Court Filing 2.0, Court Policy 2.0, Request/Response 2.0, include a number of data "lists." Lists include, for example: identifiers, descriptions, and roles for people; identifiers and roles for organizations; state abbreviations; country codes; court table names; and others. Such lists can be used to validate data, which aids consistent and accurate data collection, and are necessary for achieving interoperability among systems built by different organizations.

"Canonical lists" are similar and are related to a "data dictionary." A data dictionary is a set of data elements or terms that make up a vocabulary. A canonical list is a list of values for a given term in a data dictionary. For example, if a data dictionary term is "Gender" a canonical list for the term might include "Male," "Female," "Other," and "Unknown."

The Canonical List (Expert) document surveys the most important canonical lists in Court Filing 2.0, Court Policy 2.0, Request/Response 2.0, and CMS-API 2.0 and compares these lists with Legal XML Court Filing 1.0, Legal XML Court Filing 1.1, Office of Justice Programs Justice XML Data Dictionary 3.0, and Australian Standard 4590-1999, Interchange of Client Information.

Department of Navy XML Naming and Design Rules (Free) is an introduction to the Department of Navy ("DON") XML Naming and Design Rules, Version 2.0 ("NDR"), published January 2005. You may be familiar with the Department of Justice's ("DOJ") Global Justice XML Data Model ("GJXDM") and the <xmlLegal> Schema Framework. To provide context to the NDR, this article compares the NDR, GJXDM, and the Schema Framework, where applicable.

Part 1 of this article provides background on the DON NDR. Part 2 overviews the philosophies and rules embodied in the NDR and compares important features with GJXDM and the Schema Framework. This article compares how difference justice organizations approach solutions for legal xml.

Service Oriented Architecture ("SOA") can be implemented with Web Services, XML, CORBA, EJB, DLLs, and other technologies. Interest in SOA Services has been renewed in integration solutions, such as integrated justice, by the success of Web Services. Designing applications as SOA Services, however, requires a change in mindset on the part of those designing applications. This white paper (Free) focuses on the difference in mindset required by SOA.

Service Oriented Architecture ('SOA') White Paper

In 1998, the questions in the court, justice and legal communities were, "What is XML?" and "Should I use it four court xml and justice xml solutions?" The community was skeptical about the then new and unfamiliar technology and the proponents who advocated its use. By 2000, the community viewed XML as an acceptable, indeed, desirable information exchange technology. By 2001, the question turned to, "Should I use a DTD or XML Schema?" This question has not fully resolved itself in groups that discuss such questions. There is no doubt, however, since 2002, there has been an increase in use of W3C XML Schema ("XML Schema" or "XML Schemas"). XML Schemas are used in the <xmlLegal>Schema Framework, the California Second Generation Electronic Filing Specifications ("2GEFS"), the Global Justice XML Data Model ("GJXDM"), and the Open XML Court Interface ("OXCI"), and the Department of Navy's XML Naming and Design Rules, to name only a few technologies and projects.

XML Data Binding: Code Generation from XML Schema (Free) discusses background about code generation and then asks and answers, "What is code generation?" "Should I use a code generator?" "Are some code generators better than others?"

xmlLegal Schema Framework Reference Documents (Free) is an in-depth look at the <xmlLegal> Schema Framework that describes four example XML Schema and XML instance documents, sometimes called "reference documents." The reference documents include a state police complaint, a juvenile complaint, and a case count report and can be found on this website. The website includes source documents, output documents, XML, XML Schema, schema documentation, data dictionaries, and an example schema repository.

Fixing the Global Justice XML Data Model ('GJXDM') (Free) is the third article in a series discussing the use of XML in court and justice applications. The first article (Free), published in the November 2003 issue of the e-Filing Report, summarized the Georgia Courts Automation Commission ("GCAC") Juvenile and Child Support Electronic Court Filing Projects. The first article pointed out that in the Juvenile Project, filers submit XML documents rather than "dumb document formats." The second article, published in the December/January issue, asked and answered whether the Georgia Juvenile XML documents were based on the Office of Justice Programs Justice XML Data Dictionary ("JXDD"). The second article stated that the XML documents were not based on JXDD and went on to detail a number of issues with JXDD. This article discusses how JXDD's issues can be fixed. This article also compares and contrasts JXDD with the <xmlLegal> Schema Framework in an effort to show how the two works are complementary, not competitive.

Issues with the Justice XML Data Dictionary ('JXDD') (Free) is a follow-up article to an article in the November issue of the e-Filing Report that summarized the Georgia Courts Automation Commission ("GCAC") Juvenile and Child Support Electronic Court Filing Projects (Free). The first article pointed out that in the Juvenile Project, filers submit XML documents (within a Legal XML Court Filing 1.0 filing envelope) rather than "dumb document formats," such as Word, Word Perfect, PDF, or TIFF documents. The question has been raised, are the Juvenile XML documents based on JXDD and if not, why not? This article answers the two-part question by listed and describing eighteen issues with JXDD (now called Global Justice XML Data Model ('GJXDM')).

GCAC Juvenile and Child Support Electronic Filing Systems (Free) summarizes Georgia Courts Automation Commission ("GCAC") Juvenile and Child Support Electronic Court Filing Projects. Both projects are offshoots of the 1999-2000 GCAC Interoperability Pilot Project, in which four vendors and three courts used Legal XML Court Filing 1.0 to successfully pass filings among different test systems. Further details about each phase of the project can be found in three lessons learned documents located on the Georgia State University Electronic Court Filing website at http://e-ct-file.gsu.edu/CourtFilings/Interoperability/ or on this website in the Announcements document repository. The third lessons learned documents provides screen shots of the applications used in the projects and described in this article.

An article titled "<xmlLegal> Schema Framework Reference Documents," in the "e-Filing Report" June, 2004 issue (Vol. 4, No. 6) published by Glasser Legalworks (http://www.legalwks.com/) contains four example reference documents: a Juvenile Complaint, a State Police Complaint, a Case Count Report, and a German address.

These examples include source documents, output documents, XML, XML Schema, schema documentation, and data dictionaries.

Reference Documents