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] | [Elist Home]


Subject: RE: [legalxml-econtracts] Two Document Types Defined


I had a little different take on it. I thought there was one type of
contract, which sounds like the Contract Document that John McClure
describes below. It is a blank sheet, not unlike CourtDocument 1.1 in that
with a proper authoring tool, a WSYWIG type of document suitable for a
contract could be generated easily and suitably outputted. As a general
matter it might include the following parts in American practice, that could
be resolved to elements and attributes:

1. Parties
2. Consideration
3. Optional preamble
4. Content provisions
5. Breach
6. Remedies
7. Choice of Law and Venue

There are probably others that I have missed or forgotten. The list is not
intended to be exhaustive.

Beyond this kind of "blank sheet" type of contract, for example where the
negotiating power of the parties was largely disparate, as in an enterprise
dealing with consumers, form contracts largely with boilerplate and certain
transaction specific form inputs might be useful. These could be used to
output an XML contract possibly at a server.

In such contracts, contract administration needs could lead to other
elements and attributes being added to the outputted XML document that would
aid in determining such matters as tracking key version differences,
extracting basic price and other transaction specific information for
reports, etc.

The Policy Document that John McClure discusses possibly could be an
application for negotiation that would make use of the Contract Document to
generate standard clauses, useful to lawyers in generating drafts and
fallback positions. The trick here could be to identify the elements and
attributes of the Contract Document that would be useful or necessary to
such applications so that they would be standardized and could interoperate.

I hope this is helpful.

-----Original Message-----
From: John McClure [mailto:jmcclure@hypergrove.com]
Sent: Saturday, February 22, 2003 3:27 PM
To: 'Legalxml-Econtracts'
Cc: LEXML
Subject: [legalxml-econtracts] Two Document Types Defined


>From our last phone call, it appears that there are two (2) separate types
of
documents that this group would like to standardize. This memo is about
circumscribing the scope of these different types of documents.

1. Contract Document
	This document contains nothing but the contract, with the exception of
	(1) optional links to a "Policy Document" and to stylesheets; and
	(2) optional Dublin Core metadata.

2. Policy Document
	This document contains the negotiating parameters that one side of a
negotiation would like
	to share with the other, as well as certain workflow information.

	This document contains current forecast numbers, minimum, maximum, and
average
numbers
	for key contract provisions, expressed as they will be in dollars or days;
what
goods, premises,
	or other items are negotiable and which are not; what clauses have been
agreed
to in principle
	vs those agreed specifically; what new information is in the contract given
a
previous draft;
	what the negotiating timeline must be; what the contact information is for
each
of the negotiators;
	the set 	of minimum information (the "contract parameters") that must be
marked-up in the contract;
	a link to governing law for the contract; statements of alternative
clauses;
and other items.

My understanding from the call is that forthcoming requirements statements
will
be focusing on the content of the "Policy Document", not a "Contract"
document.

Again, I'd like to see a Contract be legally=acceptable whether encoded in
XHTML, XSL-FO, SVG, or whatever dialect is appropriate to its creating
application, perhaps an application specifically chosen by the parties to
the
contract. I continue to believe that it is not within the scope of LegalXML
to
dictate what encoding must be used for contracts, in the face of available
techniques such as annotating an XML element with a legal:names attribute
which
contains a representation of structured XML elements, e.g., <xxxx
legal:names='Contract.Party.FirstName.en'>John</xxxx>.

That said, the encoding of a <ContractPolicy> element is well-within the
purview
of this group. Comments?
John


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>



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


Powered by eList eXpress LLC