[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Requirements process
Dear TC members, I apologise for not participating earlier in this process. It takes too much time which I do not have available. I have been noting generally the exchanges and over the last few days I have taken a closer interest. Some good work has been done with the scenario development but I feel that a large part of the problem now faced by the group with various issues, including the presentation issue are the result of a failure to complete the requirements process. Due to other commitments, I am not able to commit to working up a set of requirements at the moment but would like to submit these thoughts for consideration. My concern is that the proposals emerging to date are going to frustrate the adoption of XML in law firms and other organisations, not facilitate it. It is hard to promote proprietary DTDs but it will be hard also to support a DTD that does not have a proper strategic perspective on our target user needs. I feel we need to have a clearer direction on what we are doing, for whom and why. 1. What are our real requirements? 1.1 DTD users We **seem** to be proposing a DTD that will cover the complete range of possibilities from automated electronic contract negotiation using highly standardised forms to conventional custom contract creation by lawyers working at the direction of their clients to negotiate with the other party in a conventional way. Are we serious about this? Are the requirements that same? Others (John Messing) have suggested the requirements may be different but the point does not seem to have been taken up. I doubt very much that they are the same. I believe we need to address the requirements to particular user communities and draw out their real needs more precisely than is done in the scenarios. I don't know much about the more specialised electronic contracts scenarios that some seem interested in so I won't speak to those requirements. I do have some knowledge of what lawyers do in their daily lives and can understand their needs. For example, Jason's Law firm contract scenario seems to indicate that your average lawyer will be creating contracts in XML in the near future and that this will be made possible by Office 11. Do we really think this is true? Does it matter for our requirements? I doubt very much it is true. Having looked at a beta version of the Word 11, I think it is a long way from being ready to put in front of a bunch of lawyers (I'm a lapsed lawyer). It allows the creation of invalid markup and I do not see how anyone will want to use it for complex document authoring. Even if Word 11 is considered OK as an XML document drafting tool, there are some serious questions: (a) Lawyers have to create a range of documents in their work, only some of these are contracts. As Jason correctly identifies, many contracts drafted by lawyers are included in the layout of a letter but may still have clause structures. Why should lawyers have to use a highly specific contracts DTD for contracts but another DTD or another tool (plain old Word) for other documents they create? Many other documents they create could well benefit from capture in XML markup, eg, advises, pleadings etc. This question has not been addressed at all as far as I can see. The proposed element structures use language that might describe some contracts somewhere but they represent a compromise and a jumble of terms that different constituencies use in different ways. Section is not normally used in contracts in Australia. "Clause" is more common. Still, as we know from previous discussions, there is no common understanding about what a clause really is. The problem is magnified when you try to define other parts of the document hierarchy. My personal view is that we should avoid all terms such as "article", "section", "clause" and "paragraph". These will only serve as barriers to adoption. You are asking every user group to adopt something that is in conflict with their particular citation terminology. I believe we need to develop a completely new language to describe documents that people can readily understand and map to their own citation terminology, formally or informally. Once we make this step, then we can make the next step and contemplate use of the DTD for all kinds of documents, not only contracts. As I will explain further, there are two mutually reinforcing requirements that demand we develop a generic DTD that can be used for a wide range of office documents, including contracts: (i) the need to use neutral language that does not present a barrier to users who have different citation models for essentially the same underlying structures in documents. (ii) the need to standardise systems within organisations around a common DTD. I know this can work because we do it with our own DTD. (b) How will you persuade lawyers to take up XML authoring tools? From experience and observation I can assure you its hard, even when you have a specialised group that does nothing but draft particular kinds of documents all day. They need to see clear benefits to them and it needs to make their lives easier, not harder. This will be central to the DTD you try to create. If they have to markup up all sorts of complex things, they just won't do it. Personally, I don't believe you can expect lawyers in general practice on any scale to use XML directly to create complex documents for a long time to come. It might be done with very specialised groups but it is not ready for wider use. If I am wrong and you know of examples where lawyers are using really directly drafting complex documents using XML in law firms I would be glad to hear it. (c) Where are lawyers going to exchange XML marked up contracts with other lawyers? This means that multiple law firms have to use XML. If I am right in (b) above, then this seems rather fanciful for a long time to come. (d) Where will XML really be used in law firms? My own view is that its real role will be behind the scenes for many years to come. Precedent managers will use it to maintain precedents but lawyers will interact with it indirectly, probably working in Word versions generated from the XML precedents after some initial document assembly work. More than likely, the documents they create will be word processing documents and that is what will be exchanged with other parties (or PDF) and printed for the parties to sign. If we are talking about more specialised uses for exchange of XML documents, we need to be more specific about what those users are. If we think that there will be a time (possibly quite lengthy) during which XML will gradually be taken up and used directly by authors, we need to think about that and how it affects our requirements. (e) Why is a "standard" important to our particular user groups? We seem to be proceeding on the assumption that because XML is good for certain things, a standard DTD is essential as well. Perhaps so but we should really look inside to see exactly why a standard might be useful and to whom. For example, why should law firm A use the same DTD or schema as law firm B? If they exchange data in XML form this might be useful but might it not be better to let them use their own DTDs internally to meet what ever needs they have and to translate their markup to an common format that will be exchanged with others. I mention this approach because it is what we have had to do with legislation in Australia. We work with several of the 9 jurisdictions here. Two of them are now using the same DTDs but they are not identical. We have found that each state has its own specific needs and it is not possible to use exactly the same DTD in any 2 places. Rather, they use a DTD that is substantially the same but allows differences to occur. To facilitate exchange of data with each other and to send to outsiders, they use a common exchange format that we hope will become the standard for exchange of legislation in Australia if it is adopted by one or 2 more jurisdictions. They will each have to translate in and out of the exchange markup. Why will two national law firms use the same DTD? Surely, they may each have slightly different needs. I don't actually know if this is true or not but I would assume its more likely than that everyone will sign up to an identical DTD. We should allow for that in our design. We don't want to create straight jackets for people, we want to help them to operate their businesses better. I think it will be impossible to sell a straight jacket approach. Rather, we may need to define a very simple core model and allow users to extend and adapt it to their needs. I cannot foresee exactly how this will work but am highly sceptical that a rigid standard will gain acceptance. (f) Why are contract documents different to many other kinds of documents? Yes, they have parties and signature components but the clause hierarchical structure is essentially the same as many other kinds of documents. The other differences are the numbering scheme, the citation wording and the presentation, all of which can be accommodated within a single DTD. 1.2 Are we talking about electronic contracts or contracts that are prepared using electronic technologies? We need to be clear about the differences here and direct our requirements accordingly. Why should a standard include presentation? A lot of the discussion about presentation seems to be glossing over the potential differences between an all electronic record and the more common print record of a contract. Are we trying to develop a standard that is applicable to most contract creation work or mainly for contracts with only an electronic record? There may be situations in which the only record of a contract is electronic but I believe this will be a relatively insignificant aspect of contract creation for the foreseeable future. My personal view is that the vast majority of contracts will continue to have print records so that the clients can take them away, file them, circulate them, copy them etc. Only specialised organisations have the infrastructure for purely electronic records. People without that infrastructure lose electronic records faster than they lose paper. Focussing mainly on law firm contract creation, I don't see a need to impose any presentation component. Normally, one party is primarily responsible for the contract preparation. This is usually the result of relative power relationships and tradition. The presentation of the contract will be controlled by the party who prepares the contract. Each law firm will have its own house style. Each organisation will likely have its own rendering systems to publish its documents. I very much doubt if they will rely on CSS XSLT for publishing at this stage. I can foresee a two tier approach to rendering contracts for organisations exchanging XML documents. It won't be practicable for the recipient to produce a formal print version to meet the author's standards because they won't have the author's systems. They will use different authoring and publishing tools and have different processing needs. Rather, the document can, optionally, be accompanied by a CSS that gives an approximation of the intended layout that can be rendered in the most widely available software, a web browser. This is the lowest common denominator, it is not adequate for real print publishing at this time. When it comes time to sign the document, it will be printed by the author firm, on their systems or it will be printed from something like PDF produced by the author firm. I don't think the standard needs to prescribe anything about this. I agree with those who suggest we should just make it clear that it is up to the parties to deal with presentation. 1.3 Document component numbering This issue seems to have generated some debate without resolution. Again, I think if we get our requirements right, the answer will follow. There seem to me to be three requirements that are crucial for the most common situations I envisage above: (a) We should not prescribe methods of presentation (see 1.2 above). Therefore, we cannot prescribe the application used to generate the numbers. (b) numbering schemes in contract documents will be determined by the party responsible for contract preparation. If we are going to transport XML documents, we cannot assume that the recipient could accurately generate the author's numbering scheme with any software they may have. (c) documents require cross references to numbered components. I am not a programmer, but it is my understanding you can't link to the ephemeral numbers generated by CSS. If we allow for the fact that the document can be published using many different types of software, I think the numbering has to be included in the document markup. It makes no sense to expect multiple applications to correctly interpret automatic numbering requirements. Its inaccurate and its redundant. I submit that in the most common situation, the authoring application should be responsible for generation of numbers in the document and they should be written into the markup. This does not in any way preclude automatic numbering. Rather, it facilitates an easy switch in either direction from automatic numbers to fixed and back again. This cannot be done with word processing applications. There may be specialised situations where the considerations are different. This just confirms that we have to be clear about our targets for this work. 1.4 Why a standard and what should it do? The best reasons for standardisation in law firm usage I can think of are: (a) Vendor support. One of the barriers to adoption of XML, even for specialised precedent use, is that the use of proprietary DTDs with proprietary processing software conflicts with the basic objective of XML. Firms would like to know that if they move all their data into XML format to implement a particular system, they won't have to re-do it all when they inevitably change systems in x years time. Is a rigid DTD necessary for this? (b) Sharing of authoring and processing systems with other document types. Surely, firms don't want to support multiple DTDs and have to have quite different processing systems for contracts and pleadings and then advices. I believe it is truly outrageous to suggest this should happen and is a major flaw in the whole econtracts process to date. (c) Training and support. This is really the same issue as (b) above. (d) Exchange of XML data with others. I believe this is the least important need for law firms and others dealing with contracts. Over time exchanges will occur but I believe the vast majority of contracts will be exchanged in published formats, not XML for a long time to come. Firms are not going to implement exchange processes until there is someone to exchange with. It will take a long time to build that up. In any event, lawyers don't just exchange documents with other law firms. I think this need points away from using a dedicated contracts DTD towards a more general purpose DTD. If the law firm needs to exchange XML documents with a bank or insurance company, why should the documents have to conform to a unique legal DTD? Surely it would be simpler for everyone if we can use a more general purpose DTD so that it is easier and more useful for the bank or insurance company or whomever to use. My conclusion is that a dedicated contracts DTD that is intended to be used for general purpose legal contract drafting is misconceived. It is possible we should be working with the Office documents TC to see if we can come up with something simpler for people to use. These are my personal perspectives on this problem. I understand they may not be shared by others. We don't have to agree on all these matters. We merely have to break the problem down into small components to work out what is common about our objectives. We can develop solutions to commonly identified objectives. We cannot develop solutions to a wide range of undefined and possibly inconsistent objectives. Regards Peter Meyer --------------------------------------------------------------------------- Elkera Pty Limited (ACN 092 447 428) - Knowledge management Email: pmeyer@elkera.com.au Ph: +61 2 8440 6900 * Fax: +61 2 8440 6988 http://www.elkera.com.au
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]