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

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

                          Minutes Teleconference 
                           February Sixteenth
       Organization for the Advanced of Structured Information Standards
                       Legal XML Member Section
                  eContracts Technical Committee

Present:
Dr. Zoran Milosovic
Dr. Laurence Leff
Mr. Peter Meyer
Mr. David Marvit

The meeting came to order at 18:06

There was a brief discussion of Parties.  This was deferred pending a 
proposal on this markup, which is an open action item.

We then continued with the itmes on the list.  The "list" can be found
http://www.oasis-open.org/apps/org/workgroup/legalxml-econtracts/email/
and is "Development Steps for TC Specification - revised" mailed by
Mr. Meyer on October 28th 2005.

1) List Item 2.11:

The first issue was the to use the ID and IDREF as a type of attribute when we
create the DTD or Schema.

This is an issue when constructing clause libraries.  If one had
an IDREF in one document fragment referring to an ID in another document
fragment, then one could not validate successfuly the first document.

We discussed how this issue is handled in Dita and Docbook.  Dita
does not use ID and IDREF for this reason.  Docbook uses Olinks.  One member,
reviewing the book by Dr. Bob Stayton on Docbook XSL, said that there are
specialized programs needed to manage these OLinks when they reference
across multiple documents.   Another member noted that in his
article on Docbook and Dita, Norman Walsh said that he had to turn off
the ID and IDREF mechanism.

The TC decided not to use the ID and IDREF in the main schema by default
but give an option to turn this on.  We might provide another version of
the schema where this is already turned on.  One member noted that some
users might just want to validate a contract that was all in one file.
This would be simpler than dealing with a clause library or a contract
in multiple documents.  These users might not want to take the time to learn
how to use the tools to create a new schema.  However, another member
noted that there would be many possible combinations of the
options for a schema and was concerned about simply having too many files
and schemas on the web page.

The Techncial committee deferred this issue until such time as we are preparing
the specification, and the accompanying files on the TC's web page.

2) List Item 2.12: metadata elements.

The BNML submission now has simple meta data such as title and author.
Users can add other meta data.  A reasonable source for such tags would be the 
Dublin Core; we might use others.

After the first release of the specification, users may make suggestions
to be incorporated in later releses.

3) Discussion of extension mechanisms:


Currently in the BNML schema, the core is in one file, and high-level
containers are in another file.  We anticipate that users can add elements
to these schema as defined by the rules of the schema langauge.

One could thus add blocks and items to a hypothetical high-level container
that someone might put into the second file of the schema.

4) List Item 2.13 Presentation Markup:

Should we remove elements that are oriented towards presentation?

These include the controls for automatic numbering and tags
related for emphasis.

We noted that emphasis might have legal significance as some statutes
and law requires that certain parts or statements in a contract be
emphasized.  We beleive that we will need different markup for this
statutory required emphasize as opposed to ordinary emphasis.  This might
be an attribute on a tag.

We also raised the issue of what should happen when a text-to-speech reader
for a visually-handicapped individual encoutners one of our contracts.

5) Autovalues, List Item 2.14, Variables Markup:

The current BNML  specification provides an "autovalue" mechanism that can be
used to get data from a database.  It can be used for linking.
We discussed going the other way:
for example, extracting information from a contract and putting it into
an accounting system.

We also discussed its use for the Master File Contract and Automated
Negotiation schenario.  We also noted that this is related to XFORMS.
It might be useful to have data types to validate input.  E. G., a particular
autovalue might be specified as an integer or a decimal number.

We could also specify constraints between values. (The editor notes that
this was reported in "A Constraint-Driven System for Contract Assembly"
by Daskalopulu and Sergot in 1995.)

This raises the issue of what are the use cases for these features and how
far do we go with this, particularly for the first release of the specification.
It is best to wait for practical applications before providing detail.

We noted that there were open action items for Mr. Peter Meyer to produce
proposals on various topics and Dr. Zoran Milosovic as well has action
items, particularly with reference to the Party schema.

6) Where do we go from here?

We noted that we dealt with items up to 2.14 on the list.
Item Three of the "List" stated that after dealing with those issues,
"we can prepare the actual specification."

Peter Meyer will prepare a new schema.  Then, one the schema is settle, we can 
start writing the specification.  

Dr. Milosovic will suggest a Party Schema.

We decided to aim for having the modified schema in two weeks.  
If that occurs [which it has not by March third-- editor ], 
the next meeting was to be scheduled for March Ninth.
We also decided that the TC Secretary would send copies of these minutes to 
Messrs.
Dan Greenwood and Rolly Chambers.  This is because decisions were 
made and
those people were not on this teleconference.

The meeting adjourned at 19:04 Central Time.