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