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: Re: [legalxml-econtracts] Clause Structure applied to Benchmark Contract


John

I say: The presentation  form is outside our scope.  People can create 
it - CSS, PDF, RTF, SVG, plain text etc - however they like.  How I do 
it is irrelevant.

I take it you accept the XML can be manipulated (opening it in a 
suitable XML editor which has been configured to use it, using XSLT, an 
eContracts tool or whatever) to get the presentation form which is to be 
signed (be it PDF, RTF, SVG or whatever)?

So there is nothing to tease out - there are lots of ways to get the 
presentation form.  But if doing it via XSLT turns out to be a burning 
issue for people, I'm happy to oblige. It probably wouldn't be until 
after the teleconf though, since I'm at the beach a long way from 
civilization...

You say:  We absoutely must design our XML so that CSS is able to style 
it perfectly.

To which I say that sounds like a nasty constraint... Can you help the 
TC to understand what it means by showing us 2 things:

1.  Give us an idea of how the XML would need to look to satisfy this 
hard requirement.  (Please feel welcome to transform the XML I've 
already provided if you want to do this quickly ;) )  

2.  Demonstrate that given the XML in 1 above which you need to give CSS 
its best chance, CSS is indeed up to the task.  The CSS will 
definitively answer questions such as the following:
    (a)   Do CSS implementations do hanging indents eg the number 
indented 1 inch, with the text following it indented a uniform 2 inches 
from the margin.  (I've had trouble with this in the past.)
    (b)   What browsers and other tools will display this CSS properly, 
and how does it look when printed.

I appreciate number 2 may involve significant effort on your part, but 
it does seem unavoidable given the requirement you would have the TC accept.

cheers,

Jason


John McClure wrote:

>Jason,
>As I am willing to accept your invitation, would you accept mine to provide the
>XSL-T to do the same thing with your own markup -- create the presentation form
>of the contract, that is, that thing that is signed by the users? I am
>interested in "teasing out" what your concepts are here -- if you don't think
>that XHTML/CSS is sufficient to create quality output, then it suggests that
>your general "best practices" recommendation is always to create a PDF or RTF
>rendition. right? Generating either of those with your XSL-T would be fine also.
>
>  
>
>>-----Original Message-----
>>From: Jason Harrop [mailto:jharrop@speedlegal.com]
>>Sent: Monday, April 21, 2003 9:07 AM
>>To: legalxml-econtracts@lists.oasis-open.org
>>Subject: [legalxml-econtracts] Clause Structure applied to Benchmark
>>Contract
>>
>>
>>Hi
>>
>>I suggested in the post below that to understand some of the practical
>>implications of our decision on the CSS question, we really need to see
>>how the XML would have to look in order for CSS to present it properly
>>if applied directly.
>>
>>For the purposes of comparison, I've marked up the same clause using
>>markup that I believe properly represents the content, but does not go
>>out of its way to accommodate CSS.
>>
>>For completeness, I've marked up references to parties, use and making
>>of definitions, and cross references.  Mark up along these lines is
>>useful in the law firm contract creation scenario. You'll see there are
>>lots of these, but for present purposes they can be disregarded.
>>
>>cheers,
>>
>>Jason
>>
>>Jason Harrop wrote:
>>
>>    
>>
>>>Hi Dan
>>>
>>>Yes, its a good idea to discuss this issue at this week's teleconf.
>>>
>>>But the 'first take' below invites us all to answer 'yes', without
>>>acknowledging the price we would pay for that response.
>>>
>>>Here is one way to put it which does require us to acknowledge there
>>>is a price to pay:
>>>
>>>"ALWAYS or NOT NECESSARILY: In our schema design, where choosing
>>>between representations which are convenient for CSS on the one hand,
>>>and representations which are attractive owing to other considerations
>>>(eg ease of use, economy of expression, validation), CSS concerns will
>>>ALWAYS or will NOT NECESSARILY trump all other considerations."
>>>
>>>Here is an alternative, which articulates what we are asking (fairly
>>>or unfairly) of CSS:
>>>
>>>"Yes or No: Irrespective of any other consideration (eg ease of use,
>>>economy of expression, validation), our schema must be such that when
>>>an appropriate CSS is directly applied to a XML document (valid
>>>according to the schema), the output will be of a quality that could
>>>be printed and signed."
>>>
>>>I think there are still a few more issues to tease out on the mailing
>>>list in order to ensure a productive fully informed teleconf.
>>>
>>>To this end, I invite John McClure (following Dan's "Benchmark
>>>Contracts" email) to mark up section 6.4 (just (a) to (d) would be
>>>sufficient) of the lease document at
>>>http://contracts.corporate.findlaw.com
>>>/agreements/goldman/hanover.lease.1997.08.22.html
>>>using his XML, and to provide CSS which when applied to the XML
>>>presents it as closely as CSS is capable of to that web page.  Note
>>>that each of paragraphs (a), (b), (c), (d) have headings which appear
>>>inline.
>>>
>>>I will also mark up those clauses using the labels which were agreed
>>>in the last teleconf, and the content model for those labels i have
>>>been advocating.
>>>
>>>cheers,
>>>
>>>Jason
>>>
>>>Daniel Greenwood wrote:
>>>
>>>      
>>>
>>>>Hi all,
>>>>
>>>>I think, based on the attention paid to the presentation issue on our
>>>>list, that we as a TC should formally address the question as part of
>>>>our requirements phase.  I suggest that we consider at least starting
>>>>this discussion as an agenda item during our next teleconference on
>>>>Wed.  I further suggest that we'll be more productive by carefully
>>>>articulating the question to be addressed - i.e. the requirement
>>>>statement itself.  To that end, I have talked with John McClure today
>>>>and derived the following draft statement that I think will help us to
>>>>clarify the issue before us.  Here is my first take at the question,
>>>>please feel free to hack away at it.
>>>>
>>>>"Yes or No: The eContracts spec shall define an exchange standard (XML
>>>>Schema or DTD) that includes the information needed to create
>>>>conclusive presentation of the contract as agreed by the parties,
>>>>without the need for an intervening transformation via XSL-T or
>>>>similar process."
>>>>
>>>>I think we should first agree on the question presented and then we
>>>>should determine as a group whether the answer is yes or no.
>>>>
>>>>Best regards,
>>>>Dan Greenwood
>>>>
>>>>==============================================
>>>>|  Daniel J. Greenwood, Esq.
>>>>|  Director, E-Commerce Architecture Program
>>>>|  MIT School of Architecture and Planning
>>>>|  77 Massachusetts Avenue, Room 7-231
>>>>|  Cambridge, MA 02139
>>>>|     http://ecitizen.mit.edu
>>>>|     or http://www.civics.com
>>>>|     dang@mit.edu
>>>>
>>>>        
>>>>
>>    
>>
>
>
>
>  
>




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