[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [legalxml-econtracts] Minutes Draft teleconference April 23rd2003
For ease of reference when these come up for acceptance, I've taken Dr
Leff's post, added Dave Marvit's notes of the second half, and added
Barry and Sergio to those present.
cheers,
Jason
-----------------------------------------
Minutes Teleconference of April Twenty-Third
Organization for the Advancement of Structured Information Standards
(OASIS)
Legal XML Member Section
E-Contracts Technical Committee (TC)
Present
Charles Gilliam
Dan Greenwood
Jason Harrop
Laurence L. Leff, Ph.D. (partial)
Dave Marvit
John McClure
John Messing
Barry Hansen (partial)
Sergio Maldonado (partial)
The meeting was called to order at 4:13 Eastern Time, after an informal
discussion of the topics to be covered. The group decided to cover the
concerns over presentation for display.
Several wordings on this issue to be included in the requirements were
shared by attendees. These included:
"The final Technical e-contract specification will encompass
and directly support the final conclusive displayed version of the
contract"
"The final e-contract will be of the final conclusive displayed
version of the contract"
Affirmative requirements are that there be a way to get a unique
displayed
version without specified other technologies.
Dr. Leff pointed out that some contracts may not have a display. Examples
include contracts that represent a mapping from other XML in electronic
commerce and agreements between electronic agents. It was
agreed by the group that a display not be necessary to litigate about
a contract or to have an enforceable contract. Eventual
users of the standard to emerge from this Technical Committee would not
have to use any display features. A short discussion followed of the legal
considerations in any litigation or dispute arising from a contract which
consisted of XML markup or other bits and bytes.
It was noted that the enforceability of a contract or some of its terms
may depend upon the display. Examples include waiver of warranties such
as merchantability. There was a question whether including an appropriate
attribute in the XML data stream would be sufficient to ensure that such
term be enforceability. In this case, it would be the responsibility
of the browser to display that XML in the appropriate conspicuous font.
This situation has a potential for problems if a browser did not display
the marked clause in an appropriate way.
Another question was whether PDF or RTF would be formats that we would
consider in our specifications, or would only XML-based formats be relevant.
Related was whether the XML DSignature standard include signing a PDF or RTF
document.
There was concern that if a contract be displayed in a court, it display
in the same manner as the parties saw it when it was signed. John Messing
pointed out that alleged differences in display would be decided by the
trier
of fact.
Dr. Leff excused himself to go to class, closing with an information item.
This was from the proposed minutes of the discussion of the Court Document
Standard at the recent face-to-face meeting of the Electronic Court Filing
Technical Committee:
"Printer fidelity with XML. The XML from a court document prepared
with a Court Document standard would be displayed with a browser. This
creates several issues as the court may be using a different browser
than the attorney. Would the attorney accept a situation where the
attorney would see the presentation as the court would see it and have the
opportunity to approve same before officially filing their document?
It was noted that there are fewer concerns with printer fidelity with
PDF files."
-------------------------------------------------
Dave Marvit taking over from minutes from Dr. Leff at: 2:00
Barry Hanson joined the meeting at 2:01pm
Shortly thereafter there began a discussion that centered around weather
display information should be included in our standard. This was
expressed in many different forms by both John McClure and Jason. One
example was as follows:
John McClure - [People] will apply an XSLT style sheet to an XML data
stream and people will insert data that is not from that datastream. So
the contract is entirely virtual. There is no single datastream that
represents he contract. One cannnot queary a single datastream in order
to determine the contents of a contract if it is built from multiple parts.
Jason - This is not a problem. There are really 3 scenarios.
1. You apply a transform (to the datastream to generate a PDF or some
other display format). Then the insertion is not a problem because
everyone sees the extra clauses.
2. [The data] is not being transformed into a display, but it is being
transformed into something that can be processed. But when being
processed the clauses are there.
3. [In this case] you get something which is neither of the first 2. It
is not something that will validate against our contracts format and it
is not something that people can look at and sign. If it falls into that
third category then your system will say it does not validate and then
reject it.
Dan: I believe that in some cases there wil be times when people want
to have a conclussive display so that they wil be able to understanbd
the contract better. But the goal of the spec cannot be to eliminate
fraud. That's too high a bar.
[Then we began to reformulate the question.]
John McClure: The fundamental issue is weather a data-stream purporting
to be the contract needs to be transformed in order to query it.
Jason: The question is: Is presentation in scope or out of scope?
Dan: Is that a good enough question?
John McClure: No. There are many other reasons to transform besides
display. the question should be:
"The eContrcats spec shall define an exchange standard that includes the
information needed to create the conclusive contract artifact, without
the need for an intervening transformation (by XSLT or some similar
process)." Yes or no?
Dan: So the process would be to publish the two questions to the list
and aim to answer the question at the next teleconference meeting - and
use the email list to work it around.
John Messing: If we solve a piece of the problem that will help people,
that's fine. There is plenty to solve here that will do a lot of good
without the need to address the presentation issue. Presentation, while
important, is the tail of the process. We shouldn't have the tail
wagging the dog the dog.
DanG: Rolly expressed a similar view to me [in an email sent off-list.]
John McClure expressed an interest in having a non-binding 'straw vote'.
By this time Sergio, and Charles are on the call.
Dan: The question: "Presentation, in or out."
John Messing: Out
Barry: Out
Charles: Out, but if someone wants to work on it they should be able to
work on it -- and by doing so they will gain more authority to shape how
it turns out.
Dave: Out - but I'm still trying to remain open minded
Jason: It needs to be out of scope for 2 reasons. 1. Writing our XML so
that it can be presented with out any transforms makes the XML much more
complex. 2. The method proposed, using CSS , has all kind s of problems
including interoperability across browsers.
John McClure: In, but qualified. There should be 2 streams. One is the
contract and the other has all of the other information people want -
work flow, document assembly information and so on.
Dan: It seems like display is going to come up, but it needn't be listed
as a requirement. I give it a qualified in, but there is plenty of other
stuff that we can do that is useful in either case.
John Messing: Out
At this point Sergio ventured that: "I would like to keep everything
about presentation out of it."
John McClure: I agree that this is horribly worded. The question is
"Should we exclude XSLT transforms for the XML datastream." Yes or no?
Dan - I don't think it is advisable. XSL is so useful. And that fraud
issue is out of scope. It should depend on business context.
Charles: It doesn't have to be that all of the words are on the screen.
Almost everything can be specified in terms of some set of default terms
and conditions - perhaps even by hyperlink. [Charles provided a variety
of examples where this type of model exists in the 'non-electronic'
legal world.]
John Messing: There is a concept of 'incorporation by reference'.
DanG: John, can you restate the question?
John McClure: The style sheet associated with a contract stream may only
be of type text/CSS.
[Again -- a quick straw poll]
DanG. Qualified No. Probably shouldn't be a hard and fast requirement,
but could be an option.
[Dan has to leave to catch an airplane]
Sergio: Abstain
Barry: I don't think we need to be so limited. No.
Charles : No opinion
Jason: Presentation is out of scope so I'd say nothing. So, that's a "No".
John: Yes
Dave: Abstain
Sergio: Can we put this aside for now? If this is just a technical
issue, perhaps as we move forward the solution will become clear.
Dave: These represent different philosophical points. The technical
issue (use of CSS) is a manifestation of that philosophical difference.
Jason: We need to resolve this be cause it is both a structural problem
and a philosophical one.
John: Yes, we need to look at the impact of what we are considering. We
are talking about adding a small number of elements that describe how a
document is laid out on the page.
Jason: There is a major difference in complexity. This is not minor.
The group agreed to carry on the discussion on the mailing list
The meeting was adjourned at 6:20pm EST
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]