Legal Data Markup Software CS 501 Design Presentation

Legal Data Markup Software CS 501 Design Presentation November 9 th, 2000

Project Team Sponsors Developers n Professor William Arms n Ju Joh n Professor Thomas Bruce n Sylvia Kwakye n Jason Lee n Nidhi Loyalka Reviewer n Omar Mehmood n Amy Siu n Charles Shagong n Brian Williams

Introduction n Objective: US Code (ASCII) Wellformed, valid XML output used as input to other applications Goal of end-use: Making law available for general public use

Overview n n n Development Environment Execution Environment Software Design DTD Design Packaging

Development Environment n Hardware n Server n n 233 MHz Intel PII processor 128 MB memory 28 GB hard disk Notebook Computers n n n 400 MHz Intel Celeron processor 96 MB memory 4. 7 GB hard disk

Development Environment n Software n n n Red Hat Linux 6. 2 Perl 5. 6 SSH Secure Shell 2. 3 CVS 1. 10. 7 Emacs 20. 5. 1 VIM 5. 6

Execution Environment n Caveat Client upgrades execution hardware and software environment at own risk. LDMS not guaranteed to work under new conditions.

Execution Environment n Naming Standards n General Rule n n n Filename Naming Convention n n Must start with a word in lower case. First letter of addition words in upper case. Example: the. Perl. File. pl File Name Length n Maximum of 20 characters.

Execution Environment n Naming Standards n Function Names n n n Must begin with a verb Example: initialize. Module Variable names n n Must begin with qualifiers Example: $error_Last. Error. Message

Execution Environment n Naming Standards n Filehandle Names n n Xml Output File Names n n Must be all capital letters Same as input file name with “. xml” extension DTD Element Names n n Element names in capital letters Nested element names start with DIV

Execution Environment n Coding Standards n n n A function shall not exceed 100 lines. A function shall have preceding comments on its purpose, pre- and postcondition. A variable shall have a purpose comment. Each loop shall have begin and end comments. A 3 -space indentation shall be used for each block of code.

Execution Environment n Coding Standards n n Perl contractions shall not be used. Each file shall have a modification history log. Each file shall include a copyright and license notice. Version number shall correspond to major and minor revisions to software

Software Design n System Architectural Components n n n Modules and their descriptions Design Constraints Error Handling Application Environment User Interfaces

System Architecture Program Read and Parse File Language Parsing Output Figure 1: Top-level diagram of major architectural components.

UML Component Diagram

File Parser Component

Natural Language Component

Output Component

Figure 2: UML class diagram for LDMS

Design Constraints n n n 8 -bit ASCII input files. Non-uniform title structure. Unattended operation.

Title Variation Example -CITE 11 USC Sec. 506 01/23/00 -EXPCITETITLE 11 - BANKRUPTCY CHAPTER 5 - CREDITORS, THE DEBTOR, AND THE ESTATE SUBCHAPTER I - CREDITORS AND CLAIMS -HEADSec. 506. Determination of secured status

Title Variation (cont’d) -CITE 46 USC Sec. 13102 -EXPCITETITLE 46 - SHIPPING Subtitle II - Vessels and Seamen Part I - State Boating Safety Programs CHAPTER 131 - RECREATIONAL BOATING SAFETY -HEADSec. 13102. Program acceptance 01/05/99

Error Handling n n n Handled at topmost level. Processed by Store. And. Output. Errors module. Standard report format: n Four main categories of errors.

Error Categories

Application Environment n Preconditions n n Input files must exist in a known path. Required hardware and software must be available. Sufficient system resources must be free. Postconditions n A valid, well-formed XML document conforming to our DTD will be produced.

User Interface Design n Very little runtime interactivity required. Command-line operation. Allows batch processing.

Command-Line Arguments

Status Reporting n n Frequency of status reports controlled by -L parameter. Default is no status reporting.

Module Diagrams n Diagrams can be divided into two categories: n Structural diagrams. n n Flow diagram. Behavioral diagrams. n n Culture diagram. Context diagram.

Flow Diagram U. S. Code (ASCII) House Cornell LII U. S. Code Public U. S. Code (ASCII) LDMS U. S. Code (XML)

Culture Diagram House Format of code is not negotiable. “Why does publishing take so long? ” Cornell LII Seriously faulty input must be manually resolved. LDMS XML should be double-checked. Public

Context Diagram House of Representatives Produces Legal Data Markup System Uses as Input Produces XML Executes U. S. Code Downloads Cornell Legal Information Institute Publishes

DTD Schema

The Tag Generic tag to define structural divisions. May contain , parsed character data (#PCDATA), or another . n n NAME - Label of division. VLEVEL - Depth of division. HLEVEL - Sequential order of division. EID - Globally unique identifier.

The Tag A container for sequences of fields (dashline-tagged text). May contain , , #PCDATA, or any of the field tags (MISC 1 -MISC 8, REFTEXT, COD, CHANGE, TRANS, EXEC, CROSS, SECREF).

Navigational Tags n n n - Container for navigational information, such as , , and . - Label, section number, and title. - Hierarchy of catchlines. - Individual catchline. - Name of current TOC section.

Content Tags n n - Container for actual legal data. - List of relevant sources. - Individual sources within a tag. - Amendments to a statute.

Data Tags n n n - Text that consists of a centered header, followed by content. - Header of the current data. - Cross-reference: a link to another area of the USC.

LDMS Tags in Action

LDMS Tags in Action

Packaging n Release package will include: n n Documentation Source Code Executable Files Data Files

Documentation n Source-level documentation. Program design document. DTD design document.

Source-Level Documentation n Required for inclusion in each build. Source code comments. Separate text files.

Program Design Document n n n Intended as developer/maintainer resource. High-level view of processing engine. Individual processing components. Component interfaces. Updated as development progresses.

DTD Design Document n n Resource for DTD developers and maintainers. List of all elements and use. List of all attributes and use. Modified as development progresses.

Source Code n n n Source code for prototypes will not be considered deliverables. Testing harnesses will not be considered deliverables. All source code for release version will be provided.

Executables and Data Files n n n One executable script file. No other executables will be included. DTD will be considered a deliverable.

Installation n n No installation script is planned. Path to Perl binary must be specified at head of executable script. Project directory must be copied in its entirety to desired location. Relative paths within directory must remain unchanged. User must have write permission