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: RE: [legalxml-econtracts] The Future We Want?


Hi John,

I don't exclude the matters you mention but would like to begin by covering
the most basic requirements and then use that as a platform on which to
build more specialised requirements. What I want to see is that we are clear
in the requirements so we can be clear about the specific technical
solutions that will needed to satisfy them.

Do you have a scenario statement or more detailed statement of the needs you
identify? For example, how will dispute resolution be assisted by use of XML
in contract preparation if the parties sign a printed document or if they
sign an electronic representation of the document, say PDF, as their record
of the contract? Are we talking about something that is only applicable in
very specialised types of contract or something that is of general
application?

I can't visualise how it will work so I would appreciate your detailed
thoughts on this.

I can see the use of XML markup in contract administration by a party to the
contract but I am unsure how it will assist contract negotiation. How do you
envisage this working?

regards
Peter


>
> Hi Peter:
>
> I have little problem with what you say, to the extent that I
> think I understand it.
>
> In addition to enabling legally-neutral contract instantiation,
> which is how I interpret (roughtly) what you are saying, I think
> some of us are looking at standardized terms that will facilitate
> automation via rules based and/or neural net programming in the
> following areas:
>
> 1. contract negotiation
> 2. contract administration
> 3. dispute resolution.
>
> I think these are not yet covered by your core requirements.
>
> >My core requirement would be that when we mark up the terms of a
> contract,
> >we should ensure that if the parties wish to use a plain text
> (Unicode) XML
> >file as evidence of their contract, they should be able to do so.
> >Essentially this is a requirement that the XML record should be self
> >contained as to the terms of the contract and that it does not introduce
> >ambiguity as to those terms. So, for example, all clause numbers
> and cross
> >references should be explicitly present and the hierarchical and
> grammatical
> >structure should be evident. I would go on to propose that the core,
> >structural markup must not signify any legal meaning, lest this interfere
> >with the grammatical statement of the contract terms. If in practice the
> >parties apply semantic legal markup to suit their particular processing
> >needs for an XML document that is treated as the evidentiary record, that
> >markup should be excluded from the interpretation of the
> contract, just as
> >is often the case with legislation where clause headings etc are
> treated as
> >not being part of the legislation for interpretation purposes.
> Whether the
> >standard can ensure this outcome is doubtful. Of course, if the
> parties want
> >the markup to be legally significant, that is up to them. I
> think they would
> >be heading into uncharted waters.
> >
> >When the TC was formed I and some others objected to the use of
> the term "e
> >contracts" but were out voted on that point.
> >I am interested in using XML as a means of preparing the terms
> of all of the
> >4 types of contract as a facilitative process for the parties but whether
> >XML was used along the way is no more important to the contract
> than if it
> >was done in RTF or any other markup. The most concise statement of my
> >objectives for the TC would be "To develop a standard for the
> use of XML to
> >facilitate contract preparation". When stated in this way, I
> don't see the
> >use of XML for contracts as being any different to its use for many other
> >documents prepared by lawyers and others in their day to day work.
> >
> >
> >Now that may not be everyone else's expectation so this is why we need to
> >have this discussion. What are we trying to achieve?
> >
>



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