[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes Draft from the OASIS Legal XML Member Section Electronic Contracts Technical Committee Secretary (File id: min1226)
Organization for the Advancement of Structured
Information Standards
Legal XML Member Section
eContracts Technical Committee
Minutes Teleconference of December 26th
Present: Dr. Zoran Milosovic, Mr. Peter Meyer, Dr. Laurence Leff
Mr. David Marvit, Mr. Daniel Greenwood
The group confirmed the plan in the earlier meeting plan to use BNML as is,
with one possible exeption. That would be changing the name of the tag
for Adjunct to attachment--we are likely to do this if we also decide
to make other other changes to BNML prior to using it in our specification,
particularly those changes that involve renaming other tags.
The group continued with the list of action items, and began the day's
discussions with item 2.2 on the Contract Front and Parties Markup.
It was noted that in American contracts, the parties and dates were just
included in text at the beginning of the contract, while Australia and the
United Kingdom tended to use a distinct presentation for the parties,
date and headings.
The BNML proposal has markup that acommodates both formats. However, it
does not link the markup for the address with the party information.
Elkera had not seen the need for this connection. However, the TC
determined two approaches. One could link the information to designate a
party to the address with an ID/IDREF link. Alternatively, there could be
a container for this markup. The group also discussed linking the
party with a role such as "buyer" or "seller" and having an abbreviated
name. For example, the XML might designate that "International Business
Machines" might be referred to as "IBM" in the rest of the contract.
We also noted that adding a Party element to the BNML specification
would require changes to the Elkera software to render the contracts
to a "printed" form such as PDF.
Other discussion concerned the ClickThrough scenario and noted that
simply having a URL in the party tag would be important for recording
the URL from which the ClickThrough contract came. For example,
some URL's might be on a watch list (e. g. a company
disbarred by a State Agency from doing business with the state). It
was noted that many other identifiers might be used such as the
Dun and Bradstreet Number, the Secretary of State's number for the
business or the Federal Employment Identification Number.
The group was alerted that Western Illinois University addressed the issues
of different identifiers for a business in the context of ebXML, the Business
Process Specification and interoperability between electronic commere and
litigation. That work was reported in several scholarly papers including
one on Interoperability submitted to the International Journal of Law and
Information Technology.
The TC also disussed the possibility that UBL and vCard might have good facilities for
this markup and discussed the word "metadata" in this context and noted that
this might be metadata for the Party information as contrasted with
metadata for the entire Contract XML document.
The TC set two action items. Mr. Peter Meyer agreed to send several
proposals to the TC for Party markup, probably illustrating links
between Party and Address information as well as one also a container for the Party
element. Mr. Rolly Chambers, with Mr. Daniel Greenwood as backup, will
make one or more proposals concerning using vCard, UBL or other standard
to specify this. The TC also noted that there were many needs in
this markup, and anticipating all needs would be beyond the scope of
at least the 1.0 specification. Thus, users of the specification might
add their own information to the standard. However, using an existing
standard would provide markup for much of the information that we could
anticipate users needed to include about each party to the contract.
We then moved on to item 2.3, the markup for the signatures of the Party's.
Mr. Meyer noted that the BNML specification has provisions for names of
party's, multiple signatories, witnesses. It was both "fairly complicated"
and "flexible." It was noted, as for 2.2, that the presentation is
different between contracts in Australia and UK as well as the United
States.
We noted an alternative to the proposal, that is to link semantic markup
to table markup. Although, that is not preferred, it does offer flexibility
to contract developers to have the signature block look precisely as
they want. And, we concluded that people are quite fussy as to
how this part of the contract is formatted. There are lots of issues such
as power of attorney, those who sign "in behalf of" and companies where two
directors are needed to sign a contract.
Related to this, would be recording an assent in the XML markup for the
contract. Alternatives to this is to XML for an offer and a separate XML
for the acceptance to be sent back from the offerree to the offeror.
However, it is noted that users don't currently do it this way. In many cases,
assent to a contract is simply a record in a database. The TC
noted that assent is reorded when one clicked on a button and many doubted
whether consumers would ever do assent via XML. Of course, the TC
noted whether this was in scope for the 1.0 version of the specification.
The TC decided that for the part of the specification, it would use the BNML
specification and set an action item for Mr. Peter Meyer to make proposals for
a) a link between semantics and tables for things not covered by that
specification
b) a link between the markup for signature blocks and the party information
discussed for item 2.2
The final item concerning our specification for this meeting of the TC
was item 2.4 on inline lists.
It was noted that in the U. S., it is common to have inside a paragraph with
a lettered specification as "a) ... b) ... c) ..." This is much less
common in UK and Australia.
The TC discussed whether to have markup for this. Obviously, one can just
type the letters and parentheses
in the text for the paragraph without any tags at all.
However, if the list were marked up, it would be easy for the user
to indicate in the editor that it should become a more ordinary list.
This is exemplified by the one three paragraphs above. The BNML proposal
does not currently have markup for in-line lists. Mr. Meyer observed that
the specification could allow the item tag inside a text tag
which would provide this feature to users.
The TC realized that this might not be needed in the specification for 1.0,
but people might ask us for it. The TC decided to wait for input from
the TC Members not present on this teleconference before making a
decision on this point.
The TC decided that the next meeting would be January 12th at the normal
time of 18:00 New York Time. The TC decided to continue the Thursday
time, at least for the duration of the Spring semester.
It adjourned to 19:22.
Three members had an informal discussion on Version metadata before the meeting
came to order and which continued after the meeting adjourned.
The Version Data becomes significant in two contexts or use cases. It
could be a link or information to the contract management system or
a document maagement system. It may be rendered in the contract, e. g.,
as a footer. Alternatively, it can be part of an offer-
acceptance system as identified by Anne Leith Gardner in her Artificial-
Intelligence based system for contract law, as well as the proposal for
semantic markup made by Dr. Laurence Leff, and the papers on Interoperability
from the group at Western Illinois University.
The BNML proposal has a location for the metadata for the contract.
This would be a reasonable place in which to store version information.
However, the proposal does not have specific markup for it.
Also, the group discussed the meaning of interoperability as per the
policies of OASIS. The group noted that the rules for interoperability
tests that OASIS promulgated. One possibility interoperability test
would be to have one system produce XML for a contract, have another system
read that in, edit it, and save it. Then, the first system should
be able to read it. At this stage, we would not need a formal definition
of what each system would do with the Contract XML once it read it in.
And, what does compatability mean? It an be the conformance of a system
to our specification, or it could be compliance of our specification
with some other standard such as XML Schema or Relax NG.
The group suggested that we add these issues to the agenda for the
January 12th meeting.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]