[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [legalxml-econtracts] Scenario - Law Firm Contract Creation andNegotiation - Draft 3
Hi everyone Please find attached a new draft of the above scenario. I've re-ordered the requirements so you can see how they divide in to the following 4 categories: 1. Structure 2. Markup of Inline content 3. Metainformation requirements 4. Other I've also added links to some example contracts. cheers, Jason -- Jason Harrop CTO, SPEEDLEGAL jharrop@speedlegal.com Melbourne Mob +61 (0)402 02 66 34 Tel +61 (0)3 9670 0141 Fax +61 (0)3 9670 0142 www.speedlegal.com SmartPrecedent(R) software The most intelligent way to create documentsTitle: OASIS LEGALXML ECONTRACTS TC - SCENARIO
OASIS LegalXML eContracts TC Requirements ProcessScenario - Law Firm Contract Creation and Negotiation
IntroductionThis document is a scenario developed as part of the eContracts requirements process. The purpose of a scenario is to provide a context for a set of requirements important to some group of end-users (in this case, law firms). A scenario is intended to help members of the working group to understand the drivers behind stated requirements. To that end, this document contains a Scenario Statement, and a set of Requirements extracted from the Scenario Statement. As per the requirements process, contributions to this scenario are welcome. Please send your contributions to the Scenario Owner. The Scenario Owner will decide whether to accept your contribution or not. If your contribution is not accepted, you may create your own Scenario. For further details, please refer to the eContracts Requirements Process document Scenario StatementLaw firms are currently re-evaluating their document processing strategies in light of Microsoft's announcement that the forthcoming release of Microsoft Word will be fully XML enabled (see for example http://www.microsoft.com/presspass/press/2002/Oct02/10-22Office11Beta1PR.asp). This scenario identifies some possible outcomes which an XML contract format could deliver law firms and their customers. A lawyer (or solicitor) will typically come to be working on a contract in one of two ways:
In either case, someone created an initial draft of the contract, a series of subsequent drafts were produced, and in due course (all going well), a final document acceptable to all parties is ready for signature. The initial draft will often be “cut and pasted” from an existing contract. Sometimes this existing document is a “precedent”, which a lawyer can expect to be of a high quality as a result of some precedent maintenance process. A draft contract is a version produced by the lawyer and provided to his/her client for review. (Typically the client is actively discouraged from amending a draft – amendments made by a client are best seen as instructions to the lawyer.) A draft may or may not be provided to the other side (or sides). So, the business of the lawyer is to get from the starting point (ie a blank page, a precedent, or the other side's draft) to a result his client is satisfied with, with as little pain as possible. This means negotiating favourable (or at least acceptable) terms, and reflecting those terms accurately in the words of the contract, in an efficient manner. Currently, most lawyers produce contracts using Microsoft Word (97 or later). Some still use WordPerfect. The vision for XML contracts is to improve significantly on today's typical contract production process. Improved Document QualityIt should be possible to improve the quality of a draft contract per unit of effort. Quality has several aspects to it:
XML contracts should deliver improvements in each of these areas. It must be possible to produce the vast majority of “formal” contracts currently produced in law firms. This means cover pages, table of contents, headers and footers, pictures, tables, equations, and arbitrary contents in schedules and annexures. Automatic numbering and cross-references should be supported, so the lawyer does not need to number the clauses, or worse, re-number them after a clause is inserted. Put another way, it should be possible to convert most legacy contracts into the eContracts XML format, without loss of content. It is acceptable for the formatting to be handled by a stylesheet (ie in accordance with the practice of separating content from style), provided the stylesheet can capture the format adequately. Example contracts (Australia):
Example contracts (UK): Example contracts (USA): Some contracts take the form of paragraphs in a letter. It would be good if eContracts can cover these informal contracts as well. Second, it must be possible to enforce a consistent firm style across all contracts. For example, all exclusions of liability appear in capital letters. Third, it must be possible to deliver the contract in various popular formats, including RTF, PDF, and XHTML. Better Negotiation SupportAs successive drafts are produced, the wording of various clauses will change, and some clauses will be added/removed. The lawyer needs to keep track of the state of each clause, and manage the process to an acceptable final state. It should be possible:
Word processors do not do a good job at any of this. As law firms adopt Word 11 and use its XML features to draft contracts, law firms will increasingly send their draft contracts to their client and the other parties, in XML (rather than RTF, DOC, or PDF). Alternatively, their client and the other parties will see the document in a shared workspace. In either case, it must be possible to provide an instance of the XML contract which does not contain any sensitive information, and which the other party can work with. Risk ManagementWhen a law firm drafts a contract covering say infrastructure or finance worth $1 billion, it obviously exposes the law firm to more risk than a contract with a value of say $100,000. The drafting process must address the risk. By capturing the value of the contract in the document, the workflow can automatically adapt to the value of the transaction (for example, by incorporating extra sign off steps). Downstream processingXML contracts should explicitly tag information which is necessary for the client's downstream applications. For example, information regarding the parties, the commencement, term and renewal of the contract, must be tagged so that this can be automatically captured when the contract is fed into a contract management system. Similarly, it is useful to capture the value of the contract, and any contract milestones. Particular clients are likely to have their own systems, for which special information is required (ie information specific to an industry sector like insurance, finance, or construction). It would be useful if this information could be tagged in the contract so that it can be automatically extracted. Knowledge re-use: Improved Drafting EfficiencyFirms will wish to store their precedent contracts in XML. Doing so enables the precedents to be managed more effectively. For example, if a piece of legislation changes, it should be possible to search for all contracts which contain a reference to that legislation. Precedent contracts will often have additional text which guides a lawyer in their usage. It should be easy to re-use existing precedent clauses in an XML contract. There is no reason to draft, say, a governing law clause from scratch. Equally, XML contracts should encourage lawyers to submit original or impoved clauses, so other lawyers can re-use them. Appropriate meta data must be captured, so it is easy to search across a library of existing clauses. ArchivingA law firm will often need to locate its copy of a contract, possibly many years after it was signed. It is obviously important that the document be in a format which is still readable, and it is expected that XML contracts will facilitate this. SearchIt is useful to be able to search by party, date, dollar value etc, as well as any other information which may have been tagged for the purposes of downstream applications. It is also useful to search for contracts which contain a clause of a particular type (eg termination clause), or a clause containing a certain string of words.
Application / Tool SupportLawyers must be able to create XML eContracts in the normal course of their daily practice. XML eContracts must be supported by commonly available tools. Note: this need will be taken to have been met if the XML eContract format can be handled by Microsoft Word 11. Summary of Key Benefits to Stakeholders
RequirementsThe following requirements have been extracted from the Scenario Statement. Important Note regarding Traceability: Why each requirement is important should be clear from the scenario above. If it isn't, the scenario or the requirements should be amended. STRUCTURE-related Requirements
Markup of Particular Information
MetaInformation Requirements
OTHER Requirements
NotesSome of the things in this scenario may not be delivered by the XML contract schema per se. However, it should be possible to build tools which support the requirements, using XML contracts. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]