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] Display/Presentation Agenda Item: Proposed Wording Second Draft


Hi Dan,

I'd just like to qualify the meaning of you 2nd draft question? Your
question could be read to be asking whether we will prescribe a presentation
as part of the standard?

One of the powerful underlying opportunities of xml structured documents is
the ability to render the presentation to suit the purposes of the user.
Structure, content, nomenclature, language, etc. can all be usefully
acquired or transformed from a good xml standard.

My conviction is that the TC should work towards a non-prescribed
presentation of the standard. This should be simple and ubiquitous with
perhaps multiple versions to support the various presentation options such
as XHTML, XSL, CSS and SVG.

The key point here is that we should not prescribe the presentation we
should merely exemplify the presentation as a practical extension of the
standard process.

This is an important question that will determine the direction and validity
of the TC efforts.

Thanks 

Eddie



-----Original Message-----
From: Daniel Greenwood [mailto:dang@mit.edu] 
Sent: Wednesday, April 23, 2003 2:34 PM
To: 'Legalxml-Econtracts'
Subject: [legalxml-econtracts] Display/Presentation Agenda Item: Proposed
Wording Second Draft


This is the latest way John McClure has characterized the need to address
"presentation" (e.g. display) of the contract as a requirement "Our
specification must accommodate the final XML presentation of the contract,
not a precursor to the presentation -- people sign the presentation, not the
precursor. . . I think this is the fundamental question for today - are we
exchanging a 'real' contract or not?"

The answer to these questions *could* be no.  This TC could choose to count
final contract display (i.e.: the "real contract" for many current legal
scenarios) as out of scope.  In this vein, the TC would be creating a
standard to enhance negotiation and management of contracts, but in many
situations not the "contract itself".  It is possible to include a comment
in the specification indicating the need for implementers and users to
address the displayable and executable contract through other means, and
perhaps to provide examples.  On the other hand, if this requirement is
accepted and inside the scope, then implementation of our final
specification(s) would need to reliably result in identical display between
the multiple parties to the contract.  One of the implications is that any
interoperability testing that we might need before finalization would
necessarily have to include successful demonstration of this feature.

Of course, until we determine that this is in fact a requirement, it is a
question and not an assumption.  Given all that, I propose phrasing the
requirement discussion around the following second draft wording:

[Second Draft] Yes or No: The final eContracts specification will encompass
and directly support the final, conclusive displayed version of a contract
that is agreed by the parties. [/Second Draft]

For comparison's sake, here is the prior draft: "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."

Thanks,
 - Dan Greenwood




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