OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

legalxml-econtracts message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Draft - Second half of 4/23 minutes


eContracts TC
Conference call 4/23/03
Minutes (part 2)

Note:
This meeting included a rather energetic discussion. I have done my 
best to represent what I heard, at least in spirit. If anyone feels 
misrepresented, please accept my apologies and pass a correction my 
way.  I will be happy to update the minutes.

-Dave Marvit
dave@marvit.org

-------------------------------------------------
Taking over 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]