OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: @@2432)

   Minutes of OASIS Legal XML Member Section e-Contracts Technical Committee
     Face-to-face held September 19th and September 20th at San Francisco

  Dave Berry
  Dr. Zoran Milisovic
  Peter Meyer
  Daniel Greenwood
  Dave Marvit
  Dr. Laurence Leff

1) Thanks and appreciation to Lon and David Marvit for opening up their home
   for our meeting

2) Introductions - We each introduced ourselves and told a little about
   our work with electronic Contracts

3) Mr. Greenwood shared some history of the group
    (It was recognized that Intellectual Property Issues were
     important, which included.
     a potential patent related to representing contracts.  However, at the
     suggestion of Mr. Greenwood, it was decided to proceed with the
     requirements process as if such intellectual property  was not a concern,
     so that we would come up with the best ideas unimpeded by these concerns.)

4) Mr. Greenwood said that this was a "Make or Break" meeting and it was 
   hoped that there would be a consensus on the vision and direction of this
   technical committee.

5) We also had a discussion of business process standards such as BPEL and
   Choreography and its relationship with contracts.  Also, we discussed the 
   efforts by the OASIS Technical Committee on Unified Business Languages 
   as well as the Contract Expression Language from Content
   Guard, how to liaison with these, and the possible role of James Clarke
   of OASIS, who is the liaison from the OASIS staff to our Technical Committee.

6) The Technical Committee discussed its approaches for the face-to-face.
   We would:
      for each use case
        outline the use case
        identify the transaction classes
        identify the user needs
        Come up with a vision statement (possibly two to four sentences)
      Do a high-level requirements and collapse
      Determine priorities

      [As we proceeded, we adopted a slightly different approach as you will 
       see below.]

7) Mr. Daniel Greenwood led us to a dedication and mutual dedication to
   focus, clarity, and emphasis on the business problems
   Also, we would respect each other and accept the business problem
   And, lastly, there would be open mindedness, and we are starting
   fresh on this project.

8) Midway, through the meeting, we agreed on some terminology and typology.  
   This would be an alternative to the terms: "structural" vs. "semantic" 
   and "non-narrative" vs.  "narrative"

   We recognized the importance of two types of information in a contract
     Machine-Readable would be further divided into "rules" and "data"  It
     was understood that "data" would be a special case of "rules."  as
     a single data item would be a reduced case of "rule" just as an integer
     is also a rational number.

9)  For each of the use cases, we identified the 
    a) basic statement
    b) transaction classes
    c) User Needs

(WIU Scenario Two:) 
a) A person downloads a contract to which they will assent.  They also capture
   the contract itself.
b) The two transactions are the agreement process and searching the
   set of contracts to which there was an agreement.
c) The user needs to be able to record the contracts and search the database.

(WIU Scenario One: Electronic Commerce to Litigation)
a) We convert messages in electronic commerce to one lingua-franca.  
   These may be used in court or arbitration procedures.
b) Transaction Classes are the master agreements that cover all transactions
   between the trading partners and each transaction underlying the
   commerce.  (Note, the master agreement now is a conventional signed
   document which governs the contractual relations established by the
   electronic commerce.)
c) The user needs are to recognize contract obligations.
   To match the XML documents exchanged in the normal part of exchanging
   XML documents with these obligations.
   The court should be able to recognize the electronic commerce.
   To be able to "debug" the master agreement, determine if it does give the
   needed affect to the electronic commerce and to determine that the
   contract is enforceable in various scenarios via the procedure used
   by the arbitration agency or court.

(WIU Scenario One: XML Contracts to Ligitation)
a) A contract is used and established.  The obligations are matched against
   the documents in litigation.
b) Transaction Classes are the litigation documents and the match with the
c) The user needs are to sort through the obligations and determine:
    a) if one user has a prima facie case (corresponding to a summary judgment)
    b) what must be established by the trier of fact.

a) We start with the contract:
   These are compared to the payments and to documents such as bills of
   lading or advice to determine the recognition of revenues and
b) Transaction Classes are per the normal business process
c) The user needs are to match the contract with related electronic

a) These are the creation of a contract negotiated by the partners:
   First the Basic Deal Terms are determined,
   Then the formal complete contract language is authored,
   The parties exchange these, and there may be iteration through these
   steps as issues are negotiated.
   Finally, the contract is formally adopted as recognized by both parties
   signing the contract.


This scenario includes everything that happens in negotiated contracts.
However, they start with a standard contract, such as one from the
American Institute of Architects.  Changes to these are kept, marking
with parentheses and underlines so parties can recognize these deviations
from the standard language easily.  Note that this is different from
the negotiation as expressed by Mr. Meyer as we must keep the complete
history of changes.

Then, electronic versions of the terms can go into a project-management
system.  We should be able to rapidly derive information from the
management of the contract.

We need to manage the process system.

We manage access to the contract by the stakeholder.
  They have rights and obligations and need to access (push/pull) to the
  terms.   However not all parties need access to all terms.  For example,
  the plumbers don't need to know the payment schedule or the total that
  the parties agreed to for the entire building project.
  The parties may need access in multiple formats such as print, web,
    text to speech, and via PDA.

After a change order, we need to track the new contract, that is, the
set of mutual obligations.

We recognize that the contract may consist of several documents.  These
may be prepared by different people, and some of these may be incorporated
by reference from the main contract documents.

The parties may need to check and analyze performance of parties across
multiple contracts and determine the adequacies of templates being used in
the contracts.

(This was based upon Dr. Zoran Milosovic's scenario, but not on a use
case as expressed in the template Mr. Meyer shared with us for the
September First Action deadline.)

a) This involves automated monitoring of the circumstances and compliance with
b) Interested people and persons are notified about fulfillment, their
obligations, and possible violations.


Further discussion of this scenario revealed that:

The scenario is that a person or electronic-agent interacts with the system.
(This is predominantly the web, but might include interacting with an installer
program.)  These contracts provide the terms and conditions for downloading
software, but might also include participating in a service such as
eBay or a travel agency.)

The user might have difficulty saving the document, as it might be in text
Potentially, these difficulties might lead to the contract being void under
the Federal E-Sign law.  This law provides that if a party inhibits a party
saving or printing the document, then that contract is not valid.

When the document is saved, it is difficult to name the file reasonably 
so it is very difficult to save them.  

Also, we need to track when one contract supersedes the other.  The typical
case is when a new version of the software is downloaded.

The steps are:

Step One:   The user agrees to "access an artifact" such as "online resources"
Step Two:   The user wishes to store the contract plus related "temporal data."
            These include the time of signature, the URL from which the
            document is retrieved.
Step Three: We might want to link to the software downloaded.  That is
            a person using the product might wish to be able to quickly
            access the terms under which it is used.  Similarly, if one
            has source code, one might want to link to the terms and
            conditions if that source code is to be included in another
            product, perhaps submitted to open-source repository
Step Four:  We may want to share the contracts agreed to by one party
            with another party.

Value Propositions:

A company may want all of its employees to record the contracts to which
they agree by click-through so that the legal counsel can review them.
We want to ensure that the employees do not evade this process or requirement.

We want to know if a contract supersedes any existing documents.

We may want to prevent the user from agreeing to contracts that are
contrary to corporate policy or state law.  (For example, some state
constitutions prohibit the state from "indemnifying" other parties.)

We may want an interface to digital rights management.
Corporations and legal entities may want to keep a "white list" 
and "black list" regarding specific types of terms and companies
with which it will agree or not.


Further discussion on the interoperability use case (from WIU Scenario Two)
focused on the steps in this scenario:

Step One:    A Master Document is Created
Step Two:    If this Master Document represents a trading community such as
             Covisint, people join
Step Three:  Commerce Occurs
Step Four:   Disputes occur
             a) many disputes are resolved between the parties without involving
                a third party such as an arbitrator or court
             b) other disputes would require such adjudication
Step Five:   Litigation begins
Step Six:    Adjudication occurs by arbitrary or court which leads to one of 
             two results:
                a) a summary judgment
                b) facts that are in dispute are identified.

The Technical Committee discussed how the contract litigation use case
and Accounting use case relate to this.


We need parameters.  The Technical Committee discussed how parameters
related to Document Assembly and the Interoperability scenario.  And,
the technical committee discussed whether this need was in scope; perhaps,
parameterized clauses and contracts should not be included specifically
in the specification but not precluded specifically.  We also discussed
the importance of a one-to-one mapping from parameters to the resulting

10. Scope Issues

The technical committees discussed how it would resolve scope issues:

a) Would the market accept a solution
b) What are the problems that could be resolved by a standard
c) Which use case would most further our goals? (Rolly Chambers' Construction
   Contract Management use case was selected.)
d) Which use case would impact the most users?(Click Through Contracts Scenario)

11. The Technical Committee looked at the use cases, identifying the
    goals and problems for each.



1) End users don't know what contracts they signed or their obligations
   under these agreements.
2) The party promulgating such contract (e. g. eBay or software vendors) have
   no interest or benefit in helping the end users interpret or save their
3) Systems for entering into transactions are fully created.


1) To create and preserve evidence of contracts into.  (This was identified
   as a key requirement.)
2) The Technical Committee discussed the issue of searching the saved
    contracts but did not decide anything about this requirement.

ELECTRONIC CONTRACT MANAGEMENT (based upon Peter Meyer's scenario)

1) Competition is driving the need for efficiency
2) Cost and Speed.  Iterations of negotiations are slow.  There is a transaction
                  drag on  negotiations
3) Lawyers are expensive.  Perhaps, non-lawyers can do some of this work

1) Traceability of contract changes
2) Cost and Speed, Reuse of terms is hard
3) Precedent data management
4) Repeatability - re-use reduces risks

The Technical Committee identified "reuse" as a key goal. 



1) There are disputes over change orders.  (Specifically, people interact
and act on a change order that may not be authorized.)

2) We want to ensure that the amendment process and initial assent process
are clear.)

3) One wants controlled "visibility" by different interested parties.

4) And it is hard to access the contract in different forms.

5) One wants to be able to extract items to the contract management system.

5) It is hard to reference external documents from the contract.

6) It is hard to determine the current state of contract-events, delegations,
   and processes.

7) We wish to record the past analysis of contracts of time, and parties.

Goals and objectives:

1) Automatic extraction of quantitative information from the Contract

2) Access to contract language for different output forms

3) Monitoring and tracking.  This includes reminders of dates, anticipated
   breeches, and when payments are due.

4) On-line Realtime Contract Management

5) Clear Conclusive Change-Order Management

6) Identify the current version of the contract

7) Access control to the content of the contract, and changes thereto.


The Technical Committee identified that the two use cases, both from
the same scenario, could be combined for this analysis.


1) Use of electronic commerce standards, such as ebXML, are not sufficient
   to determine if a contract is formed.

2) Currently paper contracts are used to express the "master agreement" 
   to establish a trading partner or by which new partners could
   enter into a trading community.  This represents a drag on electronic
   commerce and is one of the last bastions of paper in a world of electronic

3) Related to the above, there is no automated process for new partners
   to agree to the Trading Partner Agreement.


1) To compare the transactions with the terms of the contract

2) To have a master trading partner agreement with the ability to opt in
   with zero lawyer involvement.  Thus, it might be possible for a
   corporation to establish a "white list" of acceptable terms.

3) To provide a "lingua franca" between electronic commerce and other



1) Contract Negotiation is slow and expensive

2) There are limits to the value to partners because current negotiation 
    cannot support a large number of parameters.


1) To make contract negotiation cheap and fast.

2) To give all parties maximum practical value.

12. Table

Our technical committee worked on a table to show how each use case
corresponds to the different steps of contract formation and management
and the actors and systems relevant.  (This table was prepared in
HTML and is incorporated by reference with these minutes.)

13. Vision Statement

The technical committee observed the following introductory paragraph
or problem statement applied to all contracts:

Today, contracts are locked in blobs which can't be processed outside
the creating application (such as Microsoft Word).  This inhibits
automated document creation, information reuse, and the extraction
of information.

The Technical Committee prepared vision statements for the different
use cases:

CONTRACT DRAFTING (from Peter Meyer)

We want to allow contract terms to be managed at convenient levels of 
granularity to facilitate improved access to
the terms and conditions in precedent documents.  We want to improve
document assembly with easier harvesting of re-usable contract terms
from transaction documents.  We want to facilitate collaborative
authoring with revision history management.  And lastly, we want
to help an enterprise consistently format all of its contract


The eContracts standard will enable individuals and enterprises to
a) identify click-through contracts prior to assent
b) store contracts to which they assented
c) identify the contracts and terms assented to
when dealing with supporting online service provider.


At the moment parties to contracts and other users of contract information
have no way to exchange machine-readable contract information for 
importing into contract management systems.


To allow parties to contracts to exchange machine-readable information for importing into contract management system.  We wish to map machine-readable
contract information items to relevant human-readable contract terms.

We discussed whether the information could be exchanged as XML contracts
or attached to other forms.  It is presumptuous for us to develop a
standard that supports features not currently in contract management systems.

INTEROPERABILITY (from Dr. Laurence Leff)

In electronic commerce, there is currently no way to map or validate 
electronic transactions against the master agreement or determine the
transaction's legal effect.

There may be no master agreement and thus no way of determining the
legal affect  of transactions.  

Manual negotiation of master agreements is too time-consuming.

The following problems occurred in the context of masters agreements:

We wish to automatically update pointers when a clause is moved or changed
and update references to a document when the document location changes.


the eContract standard will enable machine-readable master contracts that
will permit:
  a) automatic validation of subordinate electronic transactions
  b) automatic contractual opt-in to participate in the system representing
     an electronic community

The technical committee will  consider whether the contract standards could
provide a "lingua franca" for processing data created from various
e-commerce standards such as ebXML.

14. Plan

At the end of our face-to-face, our technical committee briefly
identified its plan to continue its work.

Various people will do high-level requirements.  Mr. Meyer graciously
offered to provide a template and/or example.

The Technical Committee will discuss these requirements, and then
prioritize them, prior to preparing detailed requirements.

We also decided that we will probably pursue liaisons with other agencies
after requirements are done.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]