contracts and TC administrivia

["Daniel Greenwood" <dang@mit.edu>]

Jason, thanks for that.  My benchmark contracts are (belatedly) on the
way.  I'm just trying to secure permissions from the companies behind
the contracts.  I'm nearly ready to simply use publicly available
materials, if needed.

Also - if any member of the TC has a comment or idea related to the
workings of our group, I encourage you to e-mail it along today
because we're having a TC Leadership chat this evening (among the
chair, co-vice chairs and secretary).  At this meeting we'll go TC
over progress to date, resource needs for the future, administrative
planning and any other matters that seem ripe for discussion toward
the end of maintaining progress toward quality specifications and
other work products.

So - ideas and input are welcome.  Bring it on!

 - Dan

==============================================
|  Daniel J. Greenwood, Esq.
|  Director, E-Commerce Architecture Program
|  MIT School of Architecture and Planning
|  77 Massachusetts Avenue, Room 7-231
|  Cambridge, MA 02139
|     http://ecitizen.mit.edu
|     or http://www.civics.com
|     dang@mit.edu
==============================================

-----Original Message-----
From: Jason Harrop [mailto:jharrop@speedlegal.com]
Sent: Wednesday, July 23, 2003 9:59 AM
To: legalxml-econtracts@lists.oasis-open.org
Subject: Re: [legalxml-econtracts] Benchmark Contracts . . . Of
Course!

Hi everyone

I'm attaching a copy of Dan's original benchmark contracts proposal of
17 April.

IIRC, the TC subsequently adopted the idea that we all submit these.

I'm writing to remind anyone who would like to submit a benchmark
contract to please do so.  There are some in the document library
already, but I suspect the collection is not complete.

The benchmark contracts are important, since the clause model
requirements say:

"3. The clause model must be able to represent the 'benchmark'
contracts
which are submitted by members of the TC and accepted by the TC as in
scope."

Over the next few days I'd like to put together an HTML list of the
benchmark contracts and who submitted them.

Contracts can be submitted to the list, or better, put straight into
the
document library.  Since we will probably be marking them up, a format
such as HTML, text, RTF/DOC, is preferable over PDF.

thanks

Jason


Daniel Greenwood wrote:
> Dear Fellow eContracts TC Members:
>
>
>
> I think we can all be pleased with the level of progress made so far
and
> that which we are poised to make.  As our velocity toward solutions
has
> picked up, I have come to appreciate the need for even more simple
> methods of communicating and demonstrating our work to facilitate
> collaboration, visual progress metrics and mutual understanding.  In
> that spirit, I informally propose the following for consideration.
> Unless people hate the idea and say so on the list, then I will
propose
> that we formally consider it as a work method at our next meeting.
>
>
>
> I propose that each member of this TC submit one "key benchmark
> contract" and as many additional example contracts as they wish.
The
> purpose would be to have a consistent and "real world" canvas to
> visually articulate our ideas upon.  The TC would use the key
benchmark
> contracts when explaining proposed ideas.  This would assure that
> whatever ideas we are entertaining work for at least the contractual
> domains of practice represented by members of our TC.  Which this
may or
> may not be a statistically significant cross section, I believe that
it
> at least demonstrates workability in important economic sectors and
> across knowledge domains.  It also assures that whatever we are
talking
> about works, at a minimum, for those of us who are donating the
"sweat
> equity" into the standards making process.  Finally, it gives us an
> "apples to apples" method of debating any given proposal and the
> relative merits and draw backs between competing proposals.
>
>
>
> I propose that we first use this as a way to demonstrate the
decision
> (or competing options) prior to a vote on the clause issue (aka, the
> main contract content question).  If there are two or more proposed
> approaches, then as part of the discussion leading to a vote, TC
members
> should be able to see exactly how each would be applied to the
benchmark
> contracts to inform their decisions and explicitly debate the
relative
> merits and problems of each approach.  If there is only one
proposal,
> then I still think even that should be put through the test of being
> applied to the benchmark contracts so as to determine that it
"really
> works in practice" without obvious difficulty - at least in the
sample
> contractual domains represented by our varied participants.  If it
is
> desired to decide "front matter" and "back matter" (e.g. contractual
> recitals before the clauses, etc) as a second stage, then those
> proposals would be demonstrated alone upon each benchmark contract
AND
> in addition to the other structural markup already by then decided.
>
>
>
> After we have concluded the question of structure (which is itself
> always revisitable until our final specification vote, depending on
what
> other monsters we uncover as we go), then I propose that we express
the
> "legal" markup (aka "semantic" markup) applied to the benchmark
> contracts, as it is conceived and developed and debated and
ultimately
> voted upon.  This should be done directly on the content of the
> contracts, and also (prior to any final decisions) applied
cumulatively
> in addition to the structural markup and any other markup we have
decided.
>
>
>
> Of course, every mention of an idea need not be rigorously applied
to
> all or even one benchmark contract.  That would be too onerous and
would
> chill innovation, I believe.  However, to fully understand a new
idea or
> proposal once it has been seriously put forward for consideration,
it
> will be helpful to apply it to our exemplars.  Similarly, at key
> decision points (e.g. when contemplating the relative
merits/problems of
> amendments to a proposal, when voting on final or competing
proposals,
> etc) I think we should go through this process.
>
>
>
> Finally, I believe that this process will serve as a critical source
of
> knowledge management for our group in three senses.  First, as
> mentioned, it will provide a clear, consistent and familiar method
of
> communicating and evolving and reaching consensus upon ideas
throughout
> our process - this is efficient.  Second, it will give us a way to
> visually articulate what we have done and what still remains to be
done
> (we can "see" that "the structure is done, but semantics remain", or
> that "the semantics of sequence and revenue recognition are done,
but
> dispute resolution and risk allocation remain", etc).  Being able to
> visually situate us within our worksphere should reduce the
confusion
> and risk of tangents.  Third, it will serve as an excellent
repository
> of the discussions we had, the decision points we reached, the
various
> options we considered (and may wish to conveniently revisit later)
and
> the ideas we generated.  This is the essence of the digital archive
and
> the foundation of a knowledge system.  Those implementing the
standard
> later, as well as those doing future evolution of the standard, will
all
> benefit tremendously from a clear, longitudinally consistent
expression
> of our work.  It makes the impenetrable morass of plain text e-mails
and
> echo-only conference calls (i.e.: the "minutes") renderable in
knowledge
> that downstream thinkers (including ourselves) can actually access
and
> use.
>
>
>
> Finally, I note that Rolly and others (Jim, etc) have already
> instinctively done this by submitting contracts as exemplars.  This
is
> great.  To make the most of it, I think it is best for each TC
member to
> pick his or her "key" contract and consistently use that through the
> process.  Additional benchmarking contracts can and will be useful
(e.g.
> to demonstrate an especially complex structural challenge that does
not
> commonly appear in contracts but which we may wish to address via
the
> final specification).  But to assure longitudinal consistency for
> decision making and stationary goal posts, I believe it necessary to
> assure at least one span of "key" metric contracts - hence the word
> "benchmark".
>
>
>
> Thanks for consideration of this idea.  In the future, when I have
> thought ideas out better, I'll be able to communicate them is far
fewer
> words ;-)
>
>
>
> Best,
>
>  - Daniel Greenwood, eContracts TC Chair, OASIS/LegalXML
>
>
>
>
> ==============================================
> |  Daniel J. Greenwood, Esq.
> |  Director, E-Commerce Architecture Program
> |  Massachusetts Institute of Technologu
>
> |  Media Lab / School of Architecture and Planning
> |  77 Massachusetts Avenue, Room 7-231
> |  Cambridge, MA 02139
> |     http://ecitizen.mit.edu
> |     or http://www.civics.com
> |     dang@mit.edu <mailto:dang@mit.edu>
> ==============================================
>
>
>


--

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 documents


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/membe
rs/leave_workgroup.php