GO
EGUCHI and LAURENCE L. LEFF_
Computer
Science, Western Illinois University, USA
Abstract. Legal contracts and litigation
documents common to the American legal system were
encoded in the eXtensible
Markup Language (XML). XML also represents rules about the contracts
and litigation procedure. In
addition to an expert system tool that allows one to make inferences with
that engine, a Graphical User
Interface (GUI) generates the XML representing the rules. A rulebase
is developed by marking up
examples of the XML to be interpreted and the XML to be generated,
analogously to Query By
Example. This article provides a broader context of the synergy between
XML and artificial intelligence
by including discussions of: (1) the role of Artificial Intelligence in
handling routine litigation;
(2) how the use of XML enables legal expert systems to get their ‘input’
without the user having to
enter the same information again for the expert system; (3) the advantages
of XML markup over other forms
of markup for documents; (4) the relationship between XML and
ontologies; (5) other projects
using XML with rules or legal affairs.
Key words: civil procedure, contact,
expert system, graphical user interface, litigation, rules, XML
1. The setting
Some of the work that court
personnel, litigation attorneys, prosecutors, and defense
attorneys perform with
documents is routine. If the documents such as
motions, indictments, and
presentencing reports are coded, computer systems in
each of these offices can
generate new documents. Decisions that do not require
judgment or discretion can be
made by rules. Information, such as the defendant’s
name or the amount of the
prayer, can be transferred from a place on one form to
a place on another form
automatically. Information that was located and placed in
a document by one party to the
case can be extracted by another party and placed
in their software. Then their
software can put it into documents that they produce
without reentering the data or
information.
Several recent developments
have made the time ripe for applying computers
to automate this routine work
in the courts, saving staff costs and reducing errors.
The Legal XML Standards
organization has developed standards for court filing
(Halvorsen 2001) and a basic
XML standard for court documents. The former is
actively used, particularly in
the (Georgia State Interoperability Project 2001). It
provides an envelope
containing information needed to populate the records of the
_ Laurence L. Leff, Associate Professor of
Computer Science, Western Illinois University, Stipes
447, 1 University Circle,
Macomb IL 61455, USA.
284 GO EGUCHI AND LAURENCE L. LEFF
case management system for the
new filing. Legal XML Court Filing submissions
contain the pleading, motion,
order, etc. as an attachment. The receiving court
decodes it and puts it in
their document management system.
The Court Document Standard
(Abdulaziz et al. 2001) is a representation of
legal documents. It has places
to store the case caption, signature block, and certificate
of service – all common in
many different legal documents. It also has
markup for paragraphs and
lists. In particular, there are tags for ‘machine data’
which is information intended
to be exchanged or examined by software such as
the rules described below.
This is an appropriate place
to emphasize that this report represents an effort for
automating routine actions
only. Those actions that require human discretion, that
involve ‘open texture’
problems as described in Gardner (1987), are not helped by
the techniques described here.
1.1. WHY XML?
XML is a standard promulgated
by the World Wide Web Consortium for the exchange
of structured information.
This structured information includes purchase
orders, health care insurance
claims, accountant’s reports, specifications of steel
available for purchase or
sale, and real estate lending/leasing information. The
Gartner group estimates that
seventy-five percent of business-to-business electronic
transmissions will be done
using XML (Lemke 2000).
The Extensible Markup Language
(XML) is the universal format for structured
documents and data. It is
frequently used in business-to-business electronic commerce.
According to the survey
conducted by Wall
Street & Technology, more than
40 percent of Fortune 500
companies have already implemented an XML strategy,
with more than 35 percent
planning to do so in the next year (Anonymous 2001).
An alternative to XML is
electronically submitting court filings in formats such
as Adobe’s Portable Document
Format or as Microsoft Word Documents without
tags. However, it would be
difficult for a programmer to write software to extract
information. Even a simple
task like locating the case number or plaintiff’s name in
the case caption might require
artificial intelligence. This is because each submitter
might use slightly different
mechanisms to format this, even though the documents
would look the same when
printed.
Note that Adobe has introduced
a new technology called XMP, which combines
Portable Document Format and
XML. This allows these PDF documents to contain
XML tags that can be read by
software processing a workflow (Adobe 2001).
1.1.1. An aside on DTDs
An XML file has ‘tags’ to
delimit information and establish a hierarchical structure.
XML software, called a parser,
can quickly locate these tags to extract this information
or make its hierarchy
available to the application program. A key feature of
XML is the ability to define
structure, nesting, spelling of the tag names, or markup
RULE-BASED XML 285
in a document. Usually, this
is done with a DTD. A standards organization for
an industry, such as the
Organization for the Advanced of Structured Information
Standards (OASIS) Legal XML
Section, prepares a DTD for a type of document.
An application program that
accepts that type of document submits the XML and
the DTD to a validating parser
to see if the XML is ‘valid’, i.e., obeys the DTD.
This validation is most useful
for those companies that receive XML files from
many partners. As each file
comes in, it can be checked with a one-line call to
a validating parser, to ensure
that the partner did not have a bug in the program
that created the XML. This
protects their subsequent processes from the problems
caused by bad data in the
system. XML Schema provides all of the validation
capabilities of DTDs. However,
Schema allows for types of validation for which
DTDs do not provide.
For example, the Court
Document Standard 1.0 and its DTD ensure that all
complying court documents
would be marked up with tags around such information
as the plaintiff’s name, the
defendant’s address, and the information that would
normally appear in a signature
block or certificate of service. Programs at the court
would send motions to the
validating parser. After ensuring that the motion truly
followed the standard, it
could pull the information out of the XML representing
court documents.
1.2. THE ISSUE OF DATA ENTRY
When one does not mark up the
documents in some fashion, such as by XML, it
diminishes the potential
economic advantages of a legal expert system. In many of
the reports of implementation
of expert systems for legal processing (e.g., Woodin
2001), the rules do not ‘look
at’ at the documents in the case. Thus, a person
wanting to use these expert
systems must read the document and then enter the
appropriate information into
the system. Many law firms, government legal of-
fices, and law departments of
large corporations use document assembly. After
suitable configuration and
programming, the person drafting a legal document can
choose alternatives from
lists, enter the text that corresponds to a placeholder such
as ‘Name of Defendant’, or
respond to pre-programmed questions. The software
then drafts the appropriate
document. The configuration of the document assembly
software can include logic or
rules that could advise on the law of many jurisdictions.
Some have already been used to
generate a set of documents that comprised
hundreds of pages. Some
document assembly applications would be considered
artificial intelligence
(Lauritsen 1992; Lauritsen and Soudakoff 1998; Capstone
Practice Systems 2001).
In litigation, documents are
exchanged. Without a markup, it is difficult to extract
information from documents
produced from the document assembly system
at one lawyer’s office so that
it can be fed into the expert system at another lawyer’s
office. Extracting such data
would involve a major artificial intelligence project.
286 GO EGUCHI AND LAURENCE L. LEFF
In a civil case, a plaintiff
may submit a complaint containing a prayer for money
damages. If the prayer was
marked up as XML, the amount of money specified in
the prayer could be
transferred to the court’s computers for use in preparing the
judgment. Or, it could be
extracted by the computer in the defendant’s attorney’s
office for further processing.
Data entry can be a
significant issue in whether an expert system is used. In the
implementation ofMYCIN, they
found many of the expert system’s questions were
simply transcriptions of lab
results. TheMYCIN research group did not implement
a link to the hospital
information system containing this information. This was one
of the reasons that the MYCIN
system was not clinically implemented (Buchanan
and Shortliffe 1984).
2. Is XML the best way to do
this markup?
XML is one of many ways in
which information could be marked up. Alternatives
would be EDI or even a
structured ASCII format such as a comma-delimited
file. These markup types would
allow some reasoning to occur. (Western Illinois
University 2002) shows XML
mark up for several forms used in criminal justice.
Artificial intelligence
systems could read this XML and perform useful reasoning
such as the comparison of two
dates. On the other hand, one could easily imagine
much simpler markup schemes
that would allow the same reasoning to occur.
Greenspun (1995) shows the use
of an object-oriented database to contain legal
motions including complaints
and responses. Here the users enter the legal documents
using forms. XML would have
the advantage of exchanging documents
among the parties in the case
and the court. With XML, they would not have to use
the same software or the same
database.
A DTD for contracts proposed
to the Legal XML Contracts Workgroup (Leff
2000a, b) uses the structuring
capabilities of XML to allow reasoning about
the conditional structure and
temporal relation of clauses. This provides more
information than a simple list
of attributes and their values.
The primary feature of the XML
contract is a series of clauses and the implication
command. A clause is a unit of
obligation and as was pointed out in
the proposal for
standardization, any resemblance to the physical formatting of a
conventional contract is
purely coincidental.
The clause types would follow
an ontology. Currently, the DTD provides for
three clause types:
(1) payment
(2) an electronic act1
(3) a text item which is used
for any other type of obligation.
The DTD has attributes to
specify the by, to and via for the clause. For example,
the payment clause specifies
who is making the payment and who is receiving the
payment. These clauses can be
inside an XML markup for an implication. Implications
are used when a party is
obligated to do something only when something
RULE-BASED XML 287
happens. It is the contract
equivalent of an if-then statement. Implications and conditions
can reference other clauses,
and markup is provided for routine temporal
reasoning. Like many proposals
within Legal XML, the contract’s preamble includes
specific markup to list all
the ‘actors’. This mark up indicates whether each
actor is a person,
corporation, or some other type of legal entity. It also provides
basic contact information. The
by, to, and via attributes each contain the
‘ID’ of
the appropriate actor.
To illustrate these, Leff
(2000b) gives a simple contract marked up in XML (for
delivery of pizza to a
picnic.) The parties might agree on a payment amount and
that the pizza would not be
needed should it be raining on the date. Two possible
markups were given for this
situation; they only differ where the closing tag is for
the conditional. One means
that the person would pay for the pizza regardless of
whether it is raining. The
other means that the person only pays if it is not raining
and the pizza is delivered.
To contrast, the English for
this contract
1. If it is not raining, Acme
Pizza will deliver ten boxes of pizza
2. Joan will pay $100.00
is ambiguous as to whether or
not Joan is obligated to pay when it is raining and
no pizza is delivered.
Leff (2000c) shows the
modelling and markup for a commercial-type contract
for an industrial heating unit
to be delivered by Sea-Land Trucking. This was in
response to a challenge on the
Legal XML mailing list to use XML to mark up a
conventional contract: The
purchaser was specified to pay $1234.56 within 15 days
of delivery. They had one
month from the date of delivery to report any problems
with the unit to ‘Mary Lou’.
The seller would have one month from the date of
the report to make any needed
repairs. If not fixed, that contract was specified as
voided.
The process of providing
markup makes two improvements in the precision of
the contract. In the above
example, specifies what happens should it not be possible
to contact ‘Mary Lou’. She
might become unavailable due to severe illness or
death. This is done with the
Commercial Infeasibility tag. An automatic reasoning
system, inspired by the
exception mechanism in Java or C, would identify when
the contract drafters did not
consider such possibilities.
When a contract is ‘voided’,
there may be partial performance. For example, the
heating unit may have value as
scrap if not working in which case the purchaser
might want to keep it.
Conversely, a payment, if any, must be returned. Reasoning
could identify these
situations by recognizing that an item was delivered from one
party to the contract to
another. From the by
and to attributes on the clauses, it
also
would recognize that a payment
was going in the opposite direction.
All of this reasoning can be
done from an analysis of the markup and not from
analyzing the text within the
markup.
288 GO EGUCHI AND LAURENCE L. LEFF
3. Reasoning and rules with XML
Leff (2001a) demonstrated that
much reasoning can be done in contract litigation
using XML, but without
analysis of the text. The example proof-of-concept concerned
litigation about a contract
for the delivery of goods and services. The seller
was suing for payment after
completing the delivery.
The expert system read in the
following:
(1) the XML markup of the
contract
(2) the XML markup for the
complaint that initiated the lawsuit
(3) the XML markup for an
affidavit from the plaintiff that they performed the
action specified in the
contract: delivered goods
(4) the XML markup for the
request for summary judgment.
The expert system matched up
the assertion in the contract with the clause with
the contract ID. Thus, the
system did not have to deal with the text. Someone would
only need to look at the text
if the defendant filed an affidavit that referenced this
clause – perhaps to contradict
the statement or to assert that the goods were inferior.
Another rule determined the
association between the internal name in the contract
name. It created a ‘fact’.
Other rules matched this ‘fact’ against the name in
the XML markup of motions in
the case. These motions included a motion for
summary judgment, as well as
affidavits asserting that the acts to be performed in
the contract were specified.
Details can be found in Leff (2001, 2001a).
Obviously, many cases would
depend upon reading of the text and the evidence
proffered. In these cases, it
would be necessary to use open texture to resolve the
issues. However, logical
reasoning with the clauses of a contract, and the assertions
in the motions in the
litigation can resolve or simplify many cases without open
texture. When a complicated
contract is involved, they can determine which of the
issues that involve open texture
must be resolved to render a verdict.
3.1. XML MARKUP FOR RULES ABOUT XML
Leff (2001, 2001a) exemplified
writing the XML rules that control the processing
of XML documents themselves in
XML. This markup not only includes the rule
structure but how to match the
XML and how to generate new XML documents.
As typical, each rule has a
left-hand side and right-hand side. These are delineated
by the tags LHS and RHS. These can specify a fact in
the underlying expert
system. In this system, the
facts have fields, rather than being lists. The unique
feature is that the fact base
includes XML. That is, the rules can match on XML in
the fact base, and can
generate XML. The LHS
contains the
snippet of XML that
is to be matched. The RHS contains the XML to be
generated.
In the LHS, the rule writer replaces XML
attributes by ‘VariableName:nnn’
to
indicate that their value is
to go from the attribute in the corresponding position
of an input XML document and
be bound to nnn. In the RHS, this same syntax is
used to perform a substitution
from the variable into the attribute for that tag in the
same position in the XML
generated.
RULE-BASED XML 289
Similarly, one can extract a
string from the text part of a tag by using the form
_TextVariable VariableName=“nnn”\_ in the LHS. This form can also appear in
the RHS. It specifies that the
variable’s bound value is to be put in that location in
the XML generated.
This tool was used in the
simulated simple litigation, described above, about a
contract breach. The expert
system tool for XML Rules was built on top of the Java
Expert System (Jess). Jess is
a forward-chaining expert system using the RETE
engine (Friedman-Hill 1998).
It was inspired by CLIPS and the syntax of Jess’s
language is sufficiently
similar so that many CLIPS programs run in Jess. Clips,
in turn, was a C-based expert
system built at the United States National Aerospace
and Space Agency that was
inspired by OPS-5 (Riley 2002). Although Jess has
its own language, it provides
an extensive Application Program Interface (API)
to Java programmers. An API is
used to integrate the expert system with other
functionality. Java is
frequently used to write parsers and other tools for XML, for
example Apache (2002). Thus it
seemed natural to develop an expert system for
XML in Java. Each XML file in
a directory is converted into Jess facts; there is
one fact per XML tag. These
are linked by symbolic reference. The XML rules are
converted to Jess rules.
Details of this process can be found in Leff (2000).
3.2. RELATED WORK ON RULES AND XML
Other researchers are
integrating XML and rule-based technologies, as well. Business
Rules Markup Language (BRML)
allows the expression of rules in XML
(Grosof 99). These rules can
be prioritized using a partial ordering to express how
conflicts could be solved. The
theory of Courteous Logic Programs provides an
algorithm for searching a set
of rules for unresolved conflicts. It also transforms
prioritized rules into an
ordinary logic program. Their example showed how expressing
discounts and cancellation
policies could be computed for different kinds
of customers.
The RuleML project (Boley
2002) has proposed an XML DTD for the exchange
of rules on the web. Their
proposed design and DTD includes queries, as well
as facts and rules. Other
efforts include the SweetJess effort which will convert
RuleML into Jess (Ghande
2002). Also, OntoJava reads in Resource Description
Facts, ontologies specified in
Resource Description Framework, RuleML rules into
Protégé, as well as integration
using a custom java rule engine and a Java database
(Eberhart 2002). Petreley
(2002) discusses several products that handle the
propagation of changes of
business rules across various projects and applications
using XML.
The METALex project includes XML
encoding of the regulations and laws
(Boer 2002). They use both XML
and Resource Description Framework, a W3C
standard built on top of XML.
This information can be transformed to formats that
can be checked with theorem
provers as well as expert system rule engines. This
XML-format is used in querying
regulations based upon a factual situation, such as
290 GO EGUCHI AND LAURENCE L. LEFF
determining whether a
particular ship configuration is in compliance with maritime
regulation (Boer 2002a). The
XML format is also transformed into a UML model
used by the E-Power project.
This latter project can use this for modeling the
legislation for individual
cases or for the entire economy. An example effort is
used by the Dutch Tax and
Customs Administration in preparing letters assessing
whether a company’s pension
plan is in compliance with pension legislation (van
Engers 2001).
3.3. RELATED WORK ON STYLE SHEETS
AND TRANSFORMATION
TECHNIQUES
The rule-based transformations
are in contrast with XSLT. XSLT allows transformation
of XML into other XML files
and into HTML for presentation. Frequently it
is used as a style sheet. This
means the XML contains a processing instruction with
the name of an XSLT file. When
the browser is pointed at the file, it will display
the HTML generated by the XSLT
transformation. And Kay (2000) explains how
XSLT can be coded so it
corresponds to rules. But the XML that describes the
document transformation and
matching process doesn’t look like the user’s XML
input or user’s XML output
documents. And this XSLT is not created by simple
replacements on samples of the
input and output documents.
There is one idea which
contrasts uniquely with other XML efforts including
rules, style sheets and XML
Query Language (W3C 2002). That is the idea of expressing
the XML to be matched and
transformed by simply including an example
in the rule and changing a few
tags to indicate the general relationship.
4. The editor
The person developing these
rules for processing the documents, the user, begins
the task of composing the XML
form of the rule base by choosing a sample document
using the ‘Open XML Directory’
Menu. It will appear in the left hand panel.
(See Figure 1.) They use the
arrow keys below the panel to select the part that they
wish to move to the left hand
side of the new rule. As the user moves within the
XML, the relevant part of the
XML tree is displayed in red.
The user then goes to the
right hand panel and selects New Rule and New LHS
Check. Then the user selects Move From Sample. The material is moved over
and
specifies the part matched.
Then the user marks the parts
that they wish to match. They use the buttons:
RULE-BASED XML 291
Figure 1.
Change Variable
Change to Any Content
Change Attribute Variable
They replace the XML from the
sample document to use the special markup for
matching. For example, assume
the user made a string inside the tag in RED. Pressing
the ‘Change Variable’ button
would cause it to be replaced with _TextVariable
VariableName = . . . ”
Now, the user is ready to
create the right hand side. They need to select an
exemplar for the XML that will
be produced when the rule matches. After loading
this, they can use New RHS Action and Move From Sample to move the relevant
part of the rule. Then, they
use the buttons (ChangeVariable, Change to Any
Content, Change Attribute Variable) to mark this up. This time
the markup
indicates the places to
receive the data that was bound to variables by the LHS.
Lastly, the user clicks Run Expert System to run their new rule base
against
the real input.
5. Conclusions and further work
This article’s goal to answer
the question, What if documents submitted in the
course of litigation were
marked up using XML?
292 GO EGUCHI AND LAURENCE L. LEFF
Each participant in the court
system would have expert systems monitoring the
documents in the court cases
with which they are involved. The examples reported
here show how the XML markup
would allow them to do the simpler tasks. Many
of these concerned contracts –
if the logical structure of clauses and obligations
was marked up with XML, then
simpler problems are handled automatically and
the key issues to be decided
in complicated cases can be identified. Tools for developing
and executing the rules are
identified and prototypes written by the authors
are introduced.
Of course, XML does not
facilitate all Problems – many require ‘open texture’
in the sense of Gardner
(1987). Artificial Intelligence applications can be
considered on a continuum from
‘shallow’ to ‘deep’ (Doyle 1996). A tripartite
discretization of this
continuum is given by Tyree (1996). Tyree’s web page also
has an excellent explanation
why many legal problems are not a straightforward
translation of statutes and
cases into black-and-white rules. This work reports on
the techniques for solving
those problems that can be done with shallow reasoning
and the justification for
doing so.
Only an empirical analysis can
determine for sure whether these techniques
can solve significant problems
and save a significant percentage of time. Western
Illinois University is
applying for grant funding to observe court clerks handling
criminal dockets. The goal is
to determine how much time they spend on each
document-related task and by
then prototyping, identify potential savings from
XML-based automation.
We have extended the expert
system to work with XML transmitted in the
course of electronic commerce
as specified by the ebXML standard (Walsh 2002).
Trading partners use ebXML
business process specifications to precisely specify
the sequence of XML to be
exchanged to form a transaction. Another report will
show end-to-end integration of
the XML exchanged in electronic commerce to the
XML exchanged in court
documents.
Acknowledgments
The initial work on using
rules in contract litigation was done while the second author
was a Visiting Scholar at the
Massachusetts Institute of Technology Electronic
Commerce Architecture Project
during Summer 2000, in cooperation with Daniel
Greenwood, Lecturer.
James Keane, in a conversation
at the November 2000 Legal XML Face-to-
Face, suggested that the use
of an XML method to specify the rules.
This paper’s exposition was
greatly helped by two anonymous reviewers and
the Western Illinois
University Writing Center.
RULE-BASED XML 293
Note
1 Electronic acts were defined
referencing the IBM Trading Partner Agreement or an eCo architecture.
Now, such electronic acts could
also be defined by referencing a business transaction or business
document in an Extended
Business XML Business Process Specification (Walsh 2001).
References
Abdulaziz, M., Chambers, R. L.,
and Messing, J. (2001). Court Filing Document Straw Man 1.0
DTD. See
http://lists.oasis-open.org/archives/legalxml-courtfiling/200210/msg00063.html.
Adobe (2001). eXtensible
Metadata Platform. See http://www.adobe.com/products/xmp/main.html.
Al-Kofahi, K., Tyrrell, A.,
Vachher, A., and Jackson, P. (2001). A Machine Learning Approach to
Prior Case Retrieval. In
Proceedings of the International Conference on Artificial Intelligence
and Law, St. Louis. May 21–25,
2001, 88–93. Association of Computing Machinery: New York.
Anonymous (2001). Wall Street
and Technology: December 11, 2001. Also at
http://www.ilog.com/corporate/releases/us/011120_survey.cfm.
Apache Software Foundation
(2002). The XML Apache Project. See http://xml.apache.org.
Boer, A. and Willaert, F.
(2002). Guidelines for METALex Encoding of Regulations in the
Netherlands. See
http://www.metalex.nl/reports/guidelines.pdf.
Boer, A., Winkels, R., and
Hoekstra, R. (2002a). An XML Standard for Legislation in the Netherlands:
Representation of Norms in XML.
See http://www.metalex.nl/reports/normsxml.pdf.
Boley, H. (2002). The Rule
Markup Initiative. See http://www.dfki.uni-kl.de/ruleml/.
Buchanan, B. G. and Shortliffe,
E. H. (1984). Rule-Based Expert Systems: TheMYCIN Experiments
of the Stanford Heuristic
Programming Project. Addison-Wesley: Reading, MA.
Capstone Practice Systems
(2001). Web-Based Document Assembly in the Civil Legal Assistance
Community. See
http://www.lstech.org/WorkGroups/DA/webdocwhitepaper.pdf.
Doyle, J. and Dean, T. (1996).
Strategic Directions in Artificial Intelligence. ACM Computing
Surveys 28(4).
Eberhart, A. (2002). Untitled.
See http://www.i-u.de/schools/eberhart/.
Friedman-Hill, E. J. (1998).
Jess, the Expert System Shell for the Java Platform, SAND 98-8206.
Sandia National Labs.
Gardner, A. (1987). An
Artificial Intelligence Approach to Legal Reasoning. MIT Press: Cambridge,
MA.
Georgia Electronic Court Filing
Interoperability Pilot (2001). Lessons Learned Document. See
http://e-ct-file.gsu.edu/CourtFilings/.
Gandhe, M. (2002). Sweet Jess:
Introduction. See http://userpages.umbc.edu/¡«mgandh1/.
Gardner, A. L. (1987). The
Artificial Intelligence Approach to Legal Reasoning. Bradford Book:
Cambridge, MA.
Greenspun, P. and Lauritsen, M.
(1995). Making Way for Intelligence in Case Space. In The Fifth
International Conference on
Artificial Intelligence and Law: Proceedings of the Conference, May
21–24, 1995, College Park, MD.
Grosof, B. N. (1999). An
Approach to Using XML and a Rule-Based Content Language with an
Agent Communication Language.
IBM Research Report RC21491.
Halvorson, M. (2001). Draft
Court Filing 1.1 and Court Filing 1.1 DTD. See
http://www.courtxml.org/xml/JjntXmlStandard.nsf/516c7664fda1528a862565ec00504473/
8d5dcf677bf61eaa86256b25004fd2fd?OpenDocument.
Kay, M. (2000). XSLT
Programmer’s Reference. Wrox Press: Chicago.
Lauritsen, M. (1992).
Technology Report: Building Legal Practice Systems with Today’s Commercial
Authoring Tools. Artificial
Intelligence and Law 1: 87–102.
Lauritsen, M. and Soudakoff, A.
(1998). Power Tools for Document Preparation. See
http://www.capstonepractice.com/amlaw6.pdf.
294 GO EGUCHI AND LAURENCE L. LEFF
Leff, L. (2000). XML/Expert
Systems Integration with Applications to Contracts and
Litigation, MIT Electronic
Commerce Architecture Project, Document Three. See
http://ecitizen.mit.edu/ecap3.html
Leff, L. (2000a). A Standard
for Offer and Acceptance, Legal XML Document Number
UN_100XX_2000_04_22. See
http://www.wiu.edu/users/mflll/UN_100XX_2000_04_22.html
Leff, L. (2000b). Contract
Standard Update, Legal XML Document Number
UN_100XX_2000_08_22. See
http://www.wiu.edu/users/mflll/UN_100XX_2000_08_22.html
Leff, L. and Greenwood, D.
(2000). The Operating Rules Markup Language, MIT Electronic Commerce
Architecture Project, Document
One. See http://www.contractsxml.org/ecap2000/ecapgeneral00/
e-commerce/ecap3.htm
Leff, L. (2001).
Standardization of Rule-Based Processing, Transformation, and Generation of
Legal
XML Documents, Document Number
WD_100XX_2001_05_05, Version 1.0. Legal XML. See
http://www.legalxml.org/DocumentRepository/unofficialnotes/cfiling/
un_100xx_2001_05_05.html.
Leff, L. (2001a). Automated
Reasoning with Legal XML Documents. In Proceedings of the International
Conference on Artificial
Intelligence and Law, St. Louis. May 21–25, 2001, 215–216.
Association of Computing
Machinery: New York.
Lemke, T (2000) New Computer
Language to Streamline Business-to-Business e-Commerce.
Chicago Tribune, Section 4, p.
8.
Petreley, N. (2002) An XML
‘Breakthrough’. ComputerWorld 36: 20, 55.
Riley, G. (2002) Clips:
Frequently Asked Questions List. See http://www.ghg.net/clips/CLIPS-FAQ.
Tyree, A. L. (1997). The
Datalex Project. See
http://www.law.usyd.edu.au/¡«alant/boston.html#Heading5.
Van Engers (2001). Power: Using
UML/OCL for Modeling Legislation – An Application Report. In
Proceedings of the
International Conference on Artificial Intelligence and Law, St. Louis. May
21–25, 2001, 157–167.
Association of Computing Machinery: New York.
Walsh, A. E. (2002). ebXML: The
Technical Specifications. Prentice Hall: Upper Saddle River, New
Jersey.
Woodin, D. (2001). Design and
Implementation of GungaWeb: An Application of Classical Expert
System Technology to the
Production of Web-based Commercial Systems. In Proceedings of
the International Conference on
Artificial Intelligence and Law, St. Louis. May 21–25, 2001,
104–106. Association of
Computing Machinery: New York.
World-Wide Consortium (2002).
XQuery 1.0: An XML Query Language, W3C Working Draft. See
http://www.w3.org/TR/2002/WD-xquery-20020816/.
Retirado de: http://www.kluweronline.com