[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: Min0216)
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]