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