Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: min0112)

["Dr. Laurence Leff" <D-Leff@wiu.edu>]

                Minutes, Teleconference  of January 12th 2006
      Organization for the Advancement of Structured Information Standards
                        Legal XML Member Section
                      eContracts Technical Committee

Present: Dave Marvit, Peter Meyers, Rolly Chambers, Dr. Laurence Leff,
         Daniel Greenwood, Dr. Zorran Milosovic

The meeting came to order approximately 18:00.

The Legal XML Steering Committee discussed the Content Guard
patent application filed in 2003.  Two of this TC's members who were also
members of our Steering Committee reported on this.  Also, some
members looked up information on the internet during the discussion.
The Content Guard patent application includes conditions in XML, contract
expression languages.  The claims discuss an interpreted language 
that processes intentions, permissions, and bans. 

The TC discussed whether OASIS will get involved, whether Content Guard
intends to provide something that is "open," how broad the patent is, 
whether this is in the application stage or the patent has been filed.
We also discussed the legal form by which the TC might get involved.
E. G., it might be appropriate to alert the examiner at the Patent Office
of possible "prior art"  or a more formal legal action might be considered.

As a preliminary step towards this possible action,
Dr. Laurence Leff will assemble a list of some "prior art;" towards  
this, Mr. Marvit sent him the reference to the patent application.  The TC  
set this as an "action item."

The TC continued with the action items on the specification.
This was the electronic mail, "Development Steps for TC Specification --
revised."   It was sent Friday October 28th 2005 by pmeyer@elkera.com.au
Hereinafter, it will be referred to as "the list," reachable at:
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/email/
archives/200511/msg00000.html

Item 2.6 concerned whether a reference schedule should be allowed
at the front.  The BNML specification currently allows this in the back as an
"adjunct" element.   The TC decided to leave the BNML proposal  as is
on this matter.


The TC discussed items 2.7 and 2.8.  This concerns  quote or notes and how they may be numbered.  BNML 
currently has one container tag that is used for "quote" "table" "figure" 
"explanatory note" Attributes are used to  indicate which of these purposes, 
the container elment is serving.  Also, the specification has
attributes that allow for automatic number, manual numbering or to
allow a style sheet to assign the numbers.

The TC recognized the obvious alternative of having tags for
often-used purposes such as "example," "quote," etc.  The TC
also noted the reservation of having the type of number in
the markup as this is a presentation and display-related issue.

The TC decided to remove attributes that define numbering.  The 
user will put in whatever attributes they change.  The specification
will discuss options for these which include those currently used
by BNML.

The TC discussed markup at the level of phrases and key words  which  
was part of item 2.9, "additional elements."  

BNML has a "mention" tag defined.  Alternative possibilities would
be markup for "keyword" and "phrase."  These could be used for foreign
words, latin phrase, legal terms that might be indexed in "Words and
Phrases."  This would also include "terms of art" such as
"freight on board" or "Time is of the essence."

The TC discussed using a hierarchical approach, allowing 
<phrase>...<keyword>...</keyword> <keyword> ... </keyword>....</phrase>
This raised the issue of marking up differently a one-word
phrase differently from a keyword and whether one should distinguish
between them.  The alternative would be to have one tag for both
such as the mention tag already in BNML or a name such as
"significantstring" or "wordphrase"   (The TC is considering
the last term and discussed the style for tags in BNML.  Would one write
a tag as "word-phrase" "WordPhrase" or "wordPhrase")  

Many of these discussions will be revisited later, including how
this relates to the markup of Party, after we complete the other
action items on the list.

We noted that BNML allows an instance of a word to be marked up in one 
place and then to have references to it elsewhere in the document.  
This could be used to implement parameterized entries such as needed 
for Mr. Marvit's Automatic Negotiation use case and the WIU Electronic 
Commerce and Master Agreement use case. The reference could be used 
for that purpose, listing information in one place as a significant 
item and then  using the reference tag where that information must be 
substituted into the document.  

Another option is the "autovalue" that BNML provides.  It could be used to 
replace a name from a database and the above-discussed word phrase might 
also be used.

As an additional element, we briefly discussed the obvious need to
mark  up the date of a contract.  However, BNML already had defined
markup for dates.

Thus, we do not anticipate any "additional elements" at the present time.

This lead to a discussion of signatures, and the question was asked
whether BNML provides for XML signatures as envisioned by various
standards.  BNML currently provides the markup for printing a
"wet-ink" signature.

One member ased whether one must provide for XML Signatures in a standard
for a specific XML such as the eContracts standard.   Alternatively,
one might be able to hash any XML document and provide a signed version,
regardless of what standard it may obey and whether the people specifying
that standard considered signature issues.  

The TC identified four ways people might wish to address signatures and
XML.
1) one might wish to have a copy of the XML with an included signature,
   such as a JPG or GIF image of a signature
2) one might wish to simply record the presence of the signature in the
   database 
3) One might want to "challenge" the user with a password and note the   
   result of this challenge in the database.
4) One might wish to wrap the transaction, hash it and put this in
   the database.  (This is closest to the W3C XML Signature model or 
   the PKI model.)

We also noted two other possibilities: 
   1) We might use "offer" and "acceptance" where one piece of XML  
      represents the first and another piece of XML sent in response 
      represents the second.   
   2) We might want to keep a record, e. g., a "signed" bit in the
      signature tag.

In the ClickThrough Scenario, we recognized a distinction between the
language inside the scroll bar that the user reads as the contract
and the contract of assent, e. g., the text on the button that 
one clicks to "agree" to the End User License Agreement (EULA).
Although, it seems desirable to have all this in one place, the current
implementations work well in practice.   We noted that some of our sample 
markup shows that the text could be put in signature blocks.

(This also raised an issue discussed some time ago: could XML be the contract 
itself, or would one always convert it to a more human-readable form, 
e.g., PDF.)

Currently, the BNML proposal allows for the XML markup for the 
signature to contain words or an image.   Other options would be to 
put xsd:any in the signature tag.  However concerns expressed
were whether this would:
  a) break applications
  b) break renderers
  c) is this technique of supporting extendability, "a crude tool" or
     an "accepted technique."

Would a "Pen and Ink" signature be very different from a digital signature?
At this point, we may not know enough to do true digital signatures.
Digital signatures, perhaps referred to as an authentication,
would inclde PKI and W3C digital signature.
And by renaming the tag "PenAndInkSignature," those reading the specification
would not be confused by the expectation that this is for digital signatures.
We also discussed using an object-oriented approach.  That is, we define
an element called "Signature" which could be replaced by,  
as needed, PenAndInkSignature, DigitalSignature, Authenticiation, etc.  (XML Schema
supports this object-oriented approach.  -- ED.)
Authentication would be a place where one could record the language of assent
in click-through applications.
And following up on our earlier discussion, one such element, could
contain the "text of assent."

On the other hand, as existing BNML proposal supports recording text
or an image, we can support other applications by using a JPEG for "approved"
or including text
We note that the BNML handles the needs of those publishing contracts
conventionally, and is in production use for same.


Action Item: Mr. Rolly Chambers will come up with markup that might be
put in the Signature element and justification for adding this to
the specification.

Thus, for the time being, we will leave the markup as given by the BNML proposal.
However, it will be revisited twice.  Once will be upon completing the
list.   Second, we anticipate circulating the draft specification to
other groups for comment.  At this point, we can specifically draw
their attention to the issues of signatures described above.

Less Substantial and More Administrative Matters:

All outstanding minutes were approved.  One correction and/or
amplification was noted in the
minutes of the meeting of December 21st.  These concern 
Dr. Leff's remarks  Dr. Leff forwarded this to   
Mr. Marvit, who took the minutes of that meeting.  He 
had reviewed the correction
and agreed that it should be made.  Dr. Leff, as Secretary, will post
all outstanding minutes from the 2005 calendar year to the Documents
Section of our web page on the OASIS Web Site (Kavi).  These will reflect  
the above correction.

We discussed a proposal to the Legal XML Member Section steering committee
for funding regarding this specification.  It would fund:
a) an technical editor to help complete the specification
b) efforts to implement the proposal

The implementation would be taking existing software on SourceForge
and converting it to implement the proposal (the Amina and ClickThrough
projects.  This process will help
"shake out" the proposal and uncover issues where the 
specification might not clearly specify what is to be implemented.

We noted that much of the knowledge for writing the specification is with
Elkera and Peter Meyer specifically.  However, the technical editor
would have to draft some sections and ensure that the entire specification 
would be readable by those trying to use the specification but who did not have the benefit of 
being part of our discussions.

We will ask for a total  of $15,000 for these two needs.

Lastly, the Technical Committee set the date for the next teleconference 
at January 19th at 18:00 Eastern Time.