Upload
sandra-willis
View
216
Download
0
Embed Size (px)
Citation preview
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