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: 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]