[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]