[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Scenario - XML in enterprise documentation systems
Dear TC members, Attached is first draft scenario for XML in enterprise documentation systems. I would appreciate any comments or suggestions. regards Peter MeyerTitle: OASIS LEGALXML ECONTRACTS TC - SCENARIO
| Name | XML in enterprise documentation systems |
| Principal Stakeholders | Law firms, corporate legal departments, government agencies, enterprises in the finance, insurance and property management industries and software developers. |
| Scenario Owner | Peter Meyer, Elkera Pty Limited, pmeyer@elkera.com.au |
| Draft Number | 1 |
| Draft Date | 7 May 2003 |
| Contributors |
In this document:
"contract document" means a document that records the terms of a contract between parties.
"document" means a hard copy or electronic representation of a written work.
"draft" means the draft of a document that is intended to become a contract document.
"precedent" or "precedent document" means a standard form or representative example of a document that may be used as a starting point for the creation of another document, such as a contract document. It does not refer to judicial precedents.
This is a scenario for the use of XML in contracts preparation. It is for circulation of the OASIS Legal XML eContracts Technical Committee.
The mission for the TC is stated to be:
"… develop open XML standards for the markup of contract documents to enable the efficient creation, maintenance, management, exchange and publication of contract documents and contract terms."
Most enterprises who prepare contract documents, whether law firms or otherwise create many different types of documents. This scenario explores the implications of that for stakeholders and for the design of an XML DTD to describe contract terms and documents.
This scenario is concerned about steps within an enterprise that involve the creation, manipulation and preparation of draft contracts, essentially, contract document production. It aims to develop a business context for development of an e contracts DTD.
The thesis of this scenario is that as we move further out from the contract production process, the needs of users become more specialised and applicable to smaller groups of stakeholders. It is suggested that the needs of the widest group of stakeholders should be considered first with the aim of providing a platform to accommodate more specialised needs.
There are several key benefits from the use of XML in document production. These include:
The types of enterprises that might prepare a mixture of draft contracts and other document types include:
This is not an exhaustive list and the mix of contract and non contract documents will vary among these enterprises. A great many business will produce contract documents along with other business documents.
The success or otherwise of XML initiatives in contract document production for them will depend in a large measure on whether the use of XML is an enabler to allow people within the enterprise to do their work better and more effectively. Only in that way will it facilitate the achievement of wider enterprise goals.
People within document creation enterprises have to actually do the work of producing contract documents and have an interest in a possible standard. They include:
Depending on the way in which documents are created, both groups may have a vital interest in the way in which contract documents are represented in an XML based documentation system.
Document authors include:
Documentation system managers include:
Persons outside the enterprise may also have a stake in the document creation process of an enterprise. These stakeholders include:
Broadly, there are four approaches to contract document production:
Draft the contract terms from scratch. We might think this is rare since there is always some material from another contract that can be used as a starting point. However, if the author does not have a precedent in convenient format for document production, the result is the same. The document must be created from scratch, even if there is some copy typing involved.
Use a precedent document or an example from another transaction and adapt it to the particular transaction by modifying terms and drafting new terms. This is very common in law firms. It may involve some automation through the use of computer software.
Use standard form contract terms that require only the insertion of standard variable information such as parties, price, term etc. An example of such a contract is a car finance lease or a housing mortgage. Sometimes this approach is combined with case (b).
Use a set of fixed terms that are incorporated into a contract framework by other documents and conduct. Examples include a software shrink wrap licence or click through contract on a web site.
Cases 3 and 4 don't involve use of authoring software in the immediate contract formation process. The draft documents used were prepared behind the scenes by someone who used one of the approaches described in cases 1 or 2.
Cases 1 and 2 all involve some drafting work by the contract author. They are the base of the pyramid on which all contract documents are built. They are the main subjects of this scenario.
The processes used to create contract documents apply also to the creation of many other types of documents by stakeholder enterprises.
The majority of authors in stakeholder enterprises will create more than one kind of document. Most lawyers will create some or all of these:
This will be true of authors in many of the non law firm stakeholder enterprises.
These categories are not mutually exclusive. Often, contract terms are deliberately contained in a correspondence format. Contract terms may be annexed to advices or quoted in correspondence and advices.
Today, when using a word processor, authors of these kind of documents normally use only one tool to do the job. Large law firms go out of their way to develop standard approaches for all their documents. Those firms that have allowed islands to develop around document creation processes, custom databases and custom tools end up having to spend a lot of effort to standardise their practices to allow for the free flow of information and to facilitate content sharing within the organisation.
Lets assume that authors of documents will use an XML editor at some time to create contract and other documents. This is highly likely for precedent managers and other specialist authoring groups. Many believe it will become true of lawyers and other authors over time. The point is that over time, more and more authors will have to directly interact with XML markup systems and applicable markup languages.
An author of a contract document does not wish to have to learn one document markup language for contracts, another for correspondence, another for advices and yet another for litigation documents such as pleadings. To create differences in these processes is to increase the burden of training, frustrate the adoption of XML markup or create new information islands within organisations. How will an author re-use contract terms in a letter if the DTD is incompatible with the contracts DTD? What is so different about the structure of a numbered component in a contract and and one in a litigation pleading?
System managers have to provide and support the authoring systems. How will they provide and support systems around different XML markup models for different types of document? Will they find vendors who supply tools for contracts DTDs, court documents DTDs and others?
How will system managers train authors to create documents using multiple DTDs?
On top of this, each enterprise will use its own house style for document layouts. How will they apply the same house styles to multiple DTDs in a convenient way? It is costly for enterprises to develop or acquire the supporting applications to suit multiple DTDs.
From time to time, enterprises need to find new tools to assist in document management and production. Vendors come and go and technologies change. Firms merge and new common systems have to be implemented. This process has been going on since the dawn of technology. There is no evidence it will cease or even slow in the foreseeable future.
Enterprises do not want to have large volumes of valuable data tied to proprietary systems. It is costly to have to re-format large document databases when changing from one word processor to another. The more that automation systems are built into XML document production processes, the more dependencies will be created between proprietary software and data, unless very simple, standard models are developed. Today, most developers of document automation systems use highly proprietary DTDs. How will they be persuaded to abandon these in favour of standard DTDs that will give enterprises the freedom to choose tools more easily?
Enterprises engaged in document production also want better and lower cost tools. They want to foster competition.
XML based document authoring environments must be specifically customised to the DTD to provide authors with a convenient user interface. Every aspect of the authoring experience is dependent on the DTD. This is true regardless of whether the author uses a real XML editor or a forms based interface for simple document structures. The interface has to be customised to the DTD structures, including the way it accepts component numbers, internal cross references and apparently simple matters such as list creation.
If software developers wish to develop advanced automation tools for contract authoring, the chances are they will want to use those same tools to assist authors to create other kinds of documents. The processes needed to draft litigation pleadings are virtually identical to those for contracts. The same automation processes can be applied to many other kinds of documents, including many not listed earlier.
How will software vendors develop systems around multiple DTDs? It seems inconceivable that they can do so unless they are very similar in their basic architecture.
Many software developers might consider that a proprietary approach gives them an advantage. It is submitted this is antithetical to growth in the use of XML for document production, including contracts.
There is a common thread running through all the needs of all stakeholders. It is in everyone's interest to develop standardised XML markup models for use in the creation of contract and other documents by stakeholder enterprises. It is in no one's interest to have different markup models for litigation pleadings, contracts, correspondence and other documents.
A common markup model is needed for basic text structures in all the common kinds of documents created by law firms and other stakeholder enterprises.
e Contracts markup should adopt this common markup structure for the basic clause (or equivalent) structure in contracts.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]