Legal Data Markup Software

CS501 Requirements Presentation

October 4th, 2000

Project TeamDevelopers Ju Joh Sylvia Kwakye Jason Lee Nidhi Loyalka Omar Mehmood Charles

Shagong Brian Williams

Sponsors Professor William

Arms Professor Thomas

Bruce

Reviewer Amy Siu

Introduction Objective: US Code (ASCII) Well-

formed, valid XML output XML output used as input to other

applications Goal of end-use: Making law

available for general public use

References Current version of code: US Code

HTML XML tutorials and faqs Tasmanian SGML DTD’s (EnAct) W3C XML draft specification The Perl CD Bookshelf

Overview Functional Requirements Usability Requirements Minimum Performance

Requirements Design Constraints Supportability Requirements

US Code Acts of Congress (Law)

50 Titles (e.g. Armed Forces, Bankruptcy, Copyrights, Labor, Patents, Transportation)

Constantly Updated by Congress

Each Title posted online with revisions in ASCII format

Legal Information Institute Associated with Cornell’s Law

School

Founded in part by Thomas Bruce

Goal: Publish US Code on Web in a presentable format for general public

Problems Current version has difficulties

with: Overall US Code structure variations Tables, footnotes, appendices

HTML lacks archival qualities of XML, since it fails to show structural relationships.

Title 1 (LII HTML)

Title 1 (ASCII from Congress)

Title 26 (LII HTML)

Title 26 (ASCII from Congress)

Title 50 (LII HTML)

Title 50 (ASCII from Congress)

Solution LDMS will have to :

Maintain structural layout of US Code Generate cascading table of contents Allow title or full text search Markup and preserve notes Link cross-references Preserve Catch lines Generate Appendices Highlight reserved words

Functionality Directly follows from client-

specified qualities Functional requirements

Table of Contents Generation Direct representation of hierarchy inherent

to structure of US Code

Functionality Functional requirements

Appendices Generation LDMS will recognize appendix sections and

markup their constituent elements

Catchline Handling LDMS will recognize short headers in US

Code, appropriately marking them

Functionality Functional Requirements

Preservation of Cross-references LDMS will recognize self-referential links by

establishing anchors and links between text sections

Table Handling LDMS will recognize tabular data in US code, marking

up and organizing data elements into proper dimensions and indices

Functionality Functional Requirements

Preservation of Notes Critical for references, background

information, and sources LDMS will recognize notes

Reserved Words Recognition Critical attributes to entire subdivisions of

text LDMS will markup applicable text

Functionality Functional Requirements

Graceful Failures LDMS will markup unrecognizable variations in US

Code titles as such. If at all possible, LDMS will maintain readability despite the graceful failure.

Special Character Handling Non-standard characters have different meanings LDMS will recognize, markup and represent non-

conventional characters

Functionality Functional Requirements

Navigational Aids LDMS will facilitate next/previous

reference links.

Known Data Input Path Raw ASCII US Code input located in

known directory

+

+

+

+

XSL ASCII -> Unicode Word Pattern Matching Special DTD Tags White Space Pattern Matching State Machine

Appendices + + + +Special Characters + + + +Cross Ref. + + +Structural Layout + + + +Tables + + +TOC + + + + +Catch Line + + + +Notes + + + +Next/PrevGraceful Failure + + +Magic Word + + + +

Difficulty 2 1 5 3 4 6Importance 2 1 5 6 3 4Least to Most (1 to 6)

“+” Positive Correlation between two requirements.

Engineer Req.

Client Req.

House of Quality

HOQ

Usability Development and Application

Environment Red Hat Linux running on Leda

Cron daemon will execute software at client specified intervals

Two levels of users for human operation of LDMS Normal users Power users

Normal Users Computer Literacy assumed Familiarity with Linux operating system Required to start and/or stop program

from Linux command line window Application Manual provided for training 30-60 minutes expected training time

Power Users Familiarity with:

Linux operation system Perl programming language XML, DTDs and US code

Standard development directory with LDMS source code source code documentation help files, and manual page

will be provided One week expected training time

Time Estimation for Measurable Tasks

Given specifications of Leda, estimates for conversion of all fifty titles of US code to XML

30 minutes to read US Code in its entirety

12-24 hours for conversion processing

Status Messages

During execution of LDMS, display status messages at client-specified intervals, notifying the user of the progress within the current title.

Reliability Availability

Available for use 100% of the time

Mean Time Between Failures (MTBF) Product designed to fail gracefully Exceptional errors should not occur

within useful lifetime of 3 years

Reliability Mean Time To Repair (MTTR) In case of product failure, MTTR depends on nature

of fault Cause: Transient error in underlying platform MTTR: Time taken for the job to be restarted Cause: Fatal error in underlying platform MTTR: Time taken to restart the system Cause: Semantic Error within program MTTR: Requires repair by reprogramming offending part

of product Cause: Error in input.

MTTR: Time required to correct input and/or output manually.

Reliability Accuracy

Paramount to success of project Must generate XML that reproduces original

structure within defined tolerances Validation and integrity testing performed

using XSL stylesheet to view generated XML Various components and tolerance levels of

accuracy are: Structure represented by XML output: 95% accuracy Table of Contents: 95% accuracy

Reliability Reserved Words: 95% accuracy Cross-references: 75% accuracy Appendices: 75% accuracy Catchlines: 95% accuracy Preservation of Notes: 75% accuracy Handling Tables: 75% accuracy Handling Special Characters: 75%

accuracy

Reliability Acceptable Bugs

Delivering a perfect program is impossible

Bugs and defects not directly affecting usability of program or accuracy of output will be deemed tolerable

Supportability Output file naming convention

Take input filename, attach “.xml” extension

Source Level Documentation All code, Use Peer Review

Standard Unix Manual (Man) Page Program Design Document (PDD) DTD Design Document (DDD)

Performance Transaction Response Time

Average per US Code Title: 30Min. ±10Min.

Capacity: 1 Transaction at a time Resource Utilization

12MB System Memory 2MB – Interpreted Perl Code 5MB – Input data buffer 5MB – Output data buffer

Design Constraints

OS: Leda – Redhat Linux Development Language: Perl File Input: ASCII File Output: XML

Development System leda.law.cornell.e

du

233Mhz Pentium II

128MB RAM

28GB HDD

Software Interfaces

LDMS

DTD

ASCII XML

Licensing Requirements Extendable by Client

Possible Future Revenues

Might use downloaded Library Code

Joint Authorship Agreement written to address Licensing

Joint Authorship AgreementThe undersigned agree to the following:1. That all code, documentation and other copyright-protected material

produced in the course of this CS501 project (PROJECT MATERIAL) shall be understood by all to be the work of joint authors and not as a work made for hire;

2. That the joint authors shall include all the undersigned, the CS501 students working on the project and Thomas R. Bruce;

3. That despite joint authorship there will be no duty on the part of the student authors, individually or as a group, to account for any return on subsequent commercial use or development of the PROJECT MATERIAL;

4. That, in contrast, should Thomas R. Bruce or the Legal Information Institute realize royalties or other direct financial return from licensing any of the PROJECT MATERIAL there will be a duty to account to the other joint authors for any such revenue net of costs; and

5. That the undersigned will use care to assure that the PROJECT MATERIAL does not incorporate code covered by copyright and licensed on terms that are inconsistent with unlimited noncommercial distribution.

Legal, Copyright, and other Notices

No Warranty; however Developers will do their best to fulfill

requirements, but have no legal duties to do so

Applicable Standards

XML