1 / 67

Mr. James E. Cabral Jr., MTG Management Consultants, LLC

GJXDM User’s Conference. Lessons Learned From the Development and Implementation of the OASIS LegalXML Electronic Court Filing 3.0 Specification. Mr. James E. Cabral Jr., MTG Management Consultants, LLC Mr. Rex McElrath, Administrative Office of the Courts of Georgia September 6, 2006.

toya
Download Presentation

Mr. James E. Cabral Jr., MTG Management Consultants, LLC

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. GJXDM User’s Conference Lessons Learned From the Development and Implementation of the OASIS LegalXML Electronic Court Filing 3.0 Specification Mr. James E. Cabral Jr., MTG Management Consultants, LLC Mr. Rex McElrath, Administrative Office of the Courts of Georgia September 6, 2006

  2. Agenda • Introduction • Architecture • IEPD Development • Implementation • ECF Road Map 5050\01\100929(ppt)

  3. Introduction • Who Are OASIS and LegalXML? • What Does the Electronic Court Filing (ECF) Technical Committee (TC) Do? • What Happened to ECF 1.0 and 2.0? • What’s New in ECF 3.0? • How Does ECF 3.0 Relate to the GJXDM? • How Does ECF 3.0 Relate to the Justice Reference Architecture (JRA)? 5050\01\100929(ppt)

  4. IntroductionWho Are OASIS and LegalXML? • LegalXML.org Community – 1998. • Legal, court, business, academic, and technology professionals. • Collaboration on nonproprietary standards for the legal community. • Work Groups: • Court Filing. • Citations. • Contracts. • Horizontal – interoperability. • LegalXML Inc. – December 2000. • Nonprofit corporation. • Created to provide funding. 5050\01\100929(ppt)

  5. IntroductionWho Are OASIS and LegalXML? (continued) • OASIS LegalXML Member Section – March 2002. • Merged with Organization for the Advancement of Structured Information Systems (OASIS). • Advantages: • Funding, infrastructure, organization. • Part of a recognized standards body. • Proven open technical process. • A broader community – ebXML, WS-Security, SAML, UBL, etc. • Work Groups migrated to become TCs. • Active OASIS LegalXML TCs: • ECF. • Court Document Subcommittee. • Integrated Justice. • eContracts. 5050\01\100929(ppt)

  6. IntroductionWhat Does the ECF TC Do? • From the ECF TC Charter: • The TC develops specifications for the use of XML to create and transmit legal documents. • From an attorney, party, or self-represented litigant to a court. • From a court to an attorney, party, or self-represented litigant or another court. • From an attorney or other user to another attorney or other user. 5050\01\100929(ppt)

  7. IntroductionWhat Does the ECF TC Do?(continued) • From the ECF TC Charter: • Because they are essential parts of the business model for electronic filing applications, the TC will also develop specifications for: • Querying a court for data or documents. • Expressing unique court policies and requirements. • Providing legally sufficient service of court filings on other attorneys and unrepresented parties. • Linking electronic documents to law firm and court case and document management systems. • Sending and receiving payments associated with filings electronically. • Providing appropriate security to ensure the confidentiality, authenticity, correctness, and completeness of the information transmitted. 5050\01\100929(ppt)

  8. IntroductionWhat Happened to ECF 1.0 and 2.0? • Previous ECF TC specifications. • ECF 1.0 (2000). • ECF 1.1 (2001). • Court Document 1.1 (2002). • Query and Response (2002). • Status of previous specifications. • All approved by the COSCA (Conference of State Court Administrators)/NACM (National Association for Court Management) Joint Technology Committee as “proposed standards.” • All in use today by courts and vendors. • None advanced by LegalXML for approval as “recommended standards.” • The latest ECF standard is 3.0, rather than 2.0, to reflect the linkage with the GJXDM 3.0. ECF 1.x Justice XML 1.0/2.0 GJXDM 3.0.x ECF 3.0.x 5050\01\100929(ppt)

  9. IntroductionWhat’s New in ECF 3.0? • Addresses new functional/nonfunctional requirements based on experience with ECF 1.x. • Supports Standards for Electronic Filing Processes (Technical and Business Approaches) approved in 2003. • Uses schema rather than DTD. • Leverages new and emerging standards. • Vocabularies: GJXDM, UBL. • Web services: W3C, OASIS, WS-I. 5050\01\100929(ppt)

  10. IntroductionWhat’s New in ECF 3.0? (continued) • Supports electronic service as well as electronic filing and electronic access to electronic court documents and data. • Includes the data elements needed to initiate new case filings for all types of cases. • Supports payments of fees and other court obligations. • Supports queries and court policy within the court filing specification. • Incorporates advanced features of document and message authentication, integrity, and security. 5050\01\100929(ppt)

  11. IntroductionWhat’s New in ECF 3.0? (continued) • Supports some electronic service. • Supported. • Secondary Service – The delivery of copies of filed documents to persons who have already been made parties to a case. • Not supported. • Primary Service – The service of summonses, subpoenas, warrants, and other documents that establish court jurisdiction over persons, making them parties to cases. 5050\01\100929(ppt)

  12. IntroductionWhat’s New in ECF 3.0? (continued) • Supports the following case types: • Bankruptcy. • Civil (including general civil, mental health, probate, and small claims). • Criminal (both felony and misdemeanor). • Domestic relations, including divorce, separation, child custody and child support, domestic violence, and parentage (i.e., maternity or paternity). • Juvenile (both delinquency and dependency). • Traffic. 5050\01\100929(ppt)

  13. IntroductionHow Does ECF 3.0 Relate to the GJXDM? • ECF 1.x was one of the bases for Justice XML 1.0. • The ECF TC represents courts on the Global XML Structure Task Force. • The ECF TC provides feedback to the GJXDM in the development of ECF 3. 5050\01\100929(ppt)

  14. IntroductionHow Does ECF 3.0 Relate to the GJXDM?(continued) • GJXDM conformance is a core objective of ECF 3.0. • Conformance is defined by the GJXDM Implementation Guidelines. • The GJXDM is most useful for describing: • Common Objects – Person, Location. • Justice-Specific Processes – Arrest, Booking, Jail, Prosecution. • The GJXDM is not as well developed for describing non-criminal information exchanges and processes. • ECF 3.0 uses the GJXDM version 3.0.3 where the structures and definitions correspond to the requirements of ECF 3.0. 5050\01\100929(ppt)

  15. Document Incident Location Metadata Organization Person Activity Arrest Case Citation Contact Information Court IntroductionHow Does ECF 3.0 Relate to the GJXDM?(continued) ECF 3.0 messages use most GJXDM core components: • Property • Subject • Supervision • Vehicle • Warrant GJXDM Core Components 5050\01\100929(ppt)

  16. IntroductionHow Does ECF 3.0 Relate to the JRA? • The ECF architectural strategies are being followed, in modified form, by Global for the JRA. • The strategies are being considered in some form by several groups: • NIEM. • Emergency Management. • Several other possibilities. JRA 5050\01\100929(ppt)

  17. Architecture • Requirements. • Strategies. • Core specification. • Major design elements (MDEs). • Messages. • Operations. • Service interaction profiles. • Document signature profiles. • Court policies. 5050\01\100929(ppt)

  18. ArchitectureRequirements • The architecture must be flexible enough to support: • Court-supported eFiling system. • Vendor-supported eFiling system. • Court-supported eFiling system that interfaces with vendor-based applications supporting some law firms. • Many other possible combinations related to eService. 5050\01\100929(ppt)

  19. ArchitectureStrategies • Separate architectural components. • Core (messages). • Service interaction profiles. • Document signature profiles. • Policies (human and machine). • Support for multiple technical solutions. • Service interaction profiles (two so far). • Document signature profiles (five so far). 5050\01\100929(ppt)

  20. Architecture Strategies (continued) • Core specification. • Defines the MDEs and the operations and messages that are exchanged between MDEs. • Service interaction profiles. • Describe transmission system infrastructures that deliver messages between MDEs. • Document signature profiles. • Describe mechanisms for signing electronic documents. 5050\01\100929(ppt)

  21. ArchitectureStrategies (continued) • Standardized services – not applications. • Four logical interfaces (MDEs). • Messages grouped by logical interface. • Interfaces may be grouped into applications as desired. • Standardized content. • Mandate messages. • Support extensions and constraints. • Reuse GJXDM and UBL. 5050\01\100929(ppt)

  22. ArchitectureMDEs The architecture divides the electronic filing process into four MDEs and describes the messages passed between each MDE. Service MDE Filing Assembly MDE Filing Review MDE Court Record MDE 5050\01\100929(ppt)

  23. Architecture MDEs (continued) Service MDE Filing Assembly MDE Filing Review MDE Court Record MDE • Filing Assembly MDE. • Enables a filer to submit a filing and receive a response from the court. • Supports service on other parties in the case. • Filing Review MDE. • Enables a court to receive and review a filing message and respond to filers. • Prepares filings for recording in its CMS and DMS. • Enables filers to obtain court policies and status of filings. 5050\01\100929(ppt)

  24. Architecture MDEs (continued) • Court Record MDE. • Enables a court to record electronic documents and docket entries in its CMS and DMS and respond to the Filing Review MDE. • Enables filers to obtain service information, case information, and documents. • Service MDE. • Enables a party to receive service electronically from other parties in a case. Service MDE Filing Assembly MDE Filing Review MDE Court Record MDE 5050\01\100929(ppt)

  25. ArchitectureMessages • A message stream contains: • A required core message. • Basic information common to all courts and case types. • An optional case-type-specific message. • Information appropriate only for a particular type of filing. • An optional court-specific message. • Information appropriate only for cases in a particular court. Core Message Case-Type-Specific Message Court-Specific Message Attachment Attachment ECF 3.0 Message Stream 5050\01\100929(ppt)

  26. ArchitectureMessages (continued) • A message is an XML document transmitted between MDEs that validates against a message schema. • All messages are asynchronous. • Supports SOA principle of stateless design. • A message may include binary-encoded documents. • Embedded in the message using the GJXDM <j:DocumentBinaryData> element, or • Included in one or more MIME attachments to the message stream. XML 5050\01\100929(ppt)

  27. Architecture Operations • Operations are defined in the core specification, including: • Operations supported by each MDE. • The normal sequence of operations. • Business rules for each operation. 5050\01\100929(ppt)

  28. ArchitectureOperations (continued) NOTE: The bold operations are required; the others are optional. 5050\01\100929(ppt)

  29. Architecture Operations (continued) • Other query operations. • GetFilingList. • GetFilingStatus. • GetCaseList. • GetCase. • GetDocument. 5050\01\100929(ppt)

  30. ArchitectureService Interaction Profiles • Service interaction profiles support interoperability and reusability. • The core specification defines a comprehensive list of nonfunctional requirements for service interaction profiles and document signature profiles. • Each profile defines exactly how it meets and implements each nonfunctional requirement. 5050\01\100929(ppt)

  31. Architecture Service Interaction Profiles (continued) • Each service interaction profile must support: • Transport Protocol. • MDE addressing. • Operation addressing. • Request and operation invocation. • Synchronous mode response. • Asynchronous mode response. • Message/attachment delimiters. • Message identifiers. 5050\01\100929(ppt)

  32. Architecture Service Interaction Profiles (continued) • Each service interaction profile should support: • Message non-repudiation. • Message integrity. • Message confidentiality. • Message authentication. • Message reliability. • Transmission auditing. 5050\01\100929(ppt)

  33. ArchitectureService Interaction Profiles (continued) • Current service interaction profiles. • Web services (based on WS-I Basic Profile). • Portable media (sneakernet). • Potential future service interaction profiles. • HTTP (REST). • MQ. • ?? 5050\01\100929(ppt)

  34. ArchitectureDocument Signature Profiles • Each document signature profile must support: • Signer name assertion. • Signed date assertion. • Multiple signatures. 5050\01\100929(ppt)

  35. ArchitectureDocument Signature Profiles (continued) • Each document signature profile should support: • Signer and date non-repudiation. • Document integrity. • Document signature auditing. 5050\01\100929(ppt)

  36. ArchitectureDocument Signature Profiles (continued) • Currently defined document signature profiles. • Null. • XML Signature. • Application-specific. • Proxy and Symmetric Key (added). • Potential future document signature profiles. • Password. • Password/PIN. 5050\01\100929(ppt)

  37. ArchitectureCourt Policies • Court policies supports customizations and local practices through: • Human-readable court policy. • May be HTML, text, or other document format. • Court’s rules and requirements for electronic filing. • Machine-readable court policy. • Must be XML (an ECF 3.0 message). • ECF 3.0 options supported in the implementation. • Court code lists and extensions. • Design-time and run-time information. • Courts should start with small core set of information and expand as semantics can support. 5050\01\100929(ppt)

  38. ArchitectureCourt Policies (continued) • A human-readable court policy must include: • The unique court identifier. • The location of the machine-readable court policy. • A definition of what constitutes a “lead document.” • How to assign party and attorney identifiers. • A description of how the court processes (dockets) matter. • Any required elements that are optional in the schema. • Any restrictions to property values other than code lists. • Any other rules required for electronic filing in the court. 5050\01\100929(ppt)

  39. ArchitectureCourt Policies (continued) • A machine-readable court policy must include: • Run-time information that will be updated from time to time. • Code lists. • Court’s public key for digital signatures and encryption. • Development-time information that is not likely to change. • The service interaction profile(s) that the court supports. • The MDEs, operations, and case types supported by the court’s ECF 3.0 system. • Whether the court accepts URLs, documents requiring filing fees, sealed documents, or multiple (batch) filings. • Court-specific extensions, including required elements. • The maximum sizes allowed for an attachment and a message stream. 5050\01\100929(ppt)

  40. ArchitectureCourt Policies (continued) • The GJXDM extension mechanism is used to define elements in ECF 3.0 and courts may use that approach for local extensions. • However, the recommended approach for defining local extensions to ECF 3.0 is through a court-specific message. • The court-specific message is described in court policy and is made up of name-value pairs. • The name-value pairs must each include: • Cardinality. • A reference to the extension point in the core message or the case-type-specific message, expressed as an XPath substring. • Conforming applications that do not understand the court-specific message may ignore the message and its content. 5050\01\100929(ppt)

  41. ArchitectureLessons Learned • Separate functional and nonfunctional designs. • Messages vs. service interaction profiles. • Standardized services – not applications. • Leverage standards(e.g., GJXDM, UBL) for content. • Enclose documents with messages using MIME or DIME attachments rather than embedding. • Use the GJXDM extensions mechanism where possible, but multiple layers of extensions complicate interoperability. • Where appropriate, describe and enforce customizations in schema. Document the remaining customizations separately. 5050\01\100929(ppt)

  42. IEPD Development • Requirements • Domain Modeling • XML Mapping • Schema Construction • Instance Generation • Packaging 5050\01\100929(ppt)

  43. IEPD DevelopmentRequirements • Developed a comprehensive requirements document within a collaboration that included: • National and state court leaders and technologists. • Academics. • Vendors of programs and systems for courts. • Used an object-oriented analysis and design methodology. • Focused on use cases to define the information exchanges. • 26 core messages. • 6 case-type-specific messages. • Defined targets of the messages within the logical system under design. 5050\01\100929(ppt)

  44. IEPD DevelopmentDomain Modeling • Small teams built domain models for all 32 messages. • Each team consisted of two to three SMEs and one modeler/ facilitator. • Each message included definitions and constraints for all domain classes and elements. • The domain models were described in UML using ArgoUML. • The ECF TC vetted each domain model. 5050\01\100929(ppt)

  45. IEPD Development Domain Modeling (continued) 5050\01\100929(ppt)

  46. IEPD Development XML Mapping • Modelers mapped most elements to GJXDM elements. • Payment-related elements were mapped to UBL elements. • The remaining elements were identified as extension schemas and mapped to base GJXDM types. • The primary mapping tools included: • IEPD Mapping spreadsheet. • Wayfarer. 5050\01\100929(ppt)

  47. IEPD Development XML Mapping (continued) 5050\01\100929(ppt)

  48. IEPD Development Schema Construction • Modelers generated the GJXDM subset schema using the Subset Schema Generator Tool (SSGT). • Constraints were applied to the subset using an XSLT script. • Modelers used XMLSpy to construct the remaining schemas: • Common schemas (case, message, etc.). • Code list schemas. • Case-specific extension schemas. • GJXDM-based document schemas for most messages. • UBL-based document schemas for payment messages. • Schemas were validated in XMLSpy. • The ECF TC vetted each XML schema. 5050\01\100929(ppt)

  49. IEPD Development Schema Construction (continued) 5050\01\100929(ppt)

  50. IEPD Development Instance Generation • Modelers generated XML instances based on each of the 26 message schemas in XMLSpy. • Appropriate data was inserted to simulate real messages. • Instances were validated in XMLSpy and the GJXDM Validation Tool. • Instances are included in the specification but are non-normative. 5050\01\100929(ppt)

More Related