xml-dev - RE: XML for forms

["Barclay Blair" <barclay@uwi.com>]

Gavin,

>Determining admissible evidence is clearly outside the scope of
responsibility of an e-forms vendor. :-)

This reminds me of the argument that cigarette manufactures don't need
to worry  about the cancer that their cigarettes cause -- a specious
argument, but one that made them wealthy for many years.  :-)

Obviously it is the responsibility of a vendor to ensure that their users
are getting solutions that they need.  The simple fact is that any
document used in conducting business becomes part of an audit trail that
must be sound if organizations are to protect themselves.  Why should an
e-forms vendor be less responsible for this than, say, a vendor of
printed checks or multi-part forms?

>It requires that content (data) and the context (presentation) be
signed, but fusing the data content and the presentation together isn't
necessary; and it is very costly on a number of levels.

This sounds like an "e-forms vendor's" opinion on legal-related issues
to me.  Hmmn. Some legal experts wouldn't agree with your assessment.
For example:

"Historically, capturing and maintaining over time all of the major elements
of the business transaction includes: 1) the data (the content), 2) the
reason for the transaction (the context), and 3) some or all elements of the
visual and interactive presentation of the transaction (the structure). This
has been deemed to be increasingly important as the value of electronic
transactions increases. For transactions in the tens or hundreds of dollars,
the risk of loss is not that significant. Therefore, the requirement to
retain every element of detail may not be as critical for regulatory
compliance or for discovery and litigation. However, as the value of the
transaction, or the value of the information that is part of the
transaction, increases to the hundreds of thousands or even millions of
dollars, the details retained can be tantamount to winning or losing."

The full text is available at: http://www.cohasset.com/comm_forms.html
if you are interested in more information.

Barclay


 ============================================
    Barclay Blair -- Industry Relations
    UWI.Com -- The InternetForms Company
  v: 250-479-8334 x161   fx: 250-479-3772
 barclay@uwi.com	       www.uwi.com
============================================

-----Original Message-----
From: owner-xml-dev@ic.ac.uk [mailto:owner-xml-dev@ic.ac.uk]On Behalf Of
Gavin McKenzie
Sent: Monday, July 05, 1999 1:06 PM
To: 'Tim Bray'; David Megginson; xml-dev@ic.ac.uk
Subject: RE: XML for forms



Tim Bray writes:
> Emulating paper isn't the issue; making the transaction admissable
> as evidence is.

Determining admissible evidence is clearly outside the scope of
responsibility of an e-forms vendor. :-)

> That is why XFDL for example insists on including
> in the form document all the presentational information and so on -
> the claim is that you have to digitally sign not only the answers to
> the questions but the questions and how they were presented to the
> user, in order to achieve the goal of non-repudiation.  (Mind you,
> this should be done using CSS or flow objects rather than with
> custom tags as XFDL did).

Sign yes. Include no.  It requires that content (data) and the context
(presentation) be signed, but fusing the data content and the presentation
together isn't necessary; and it is very costly on a number of levels.

Simply including a fingerprint of the presentation as part of the data
signing is sufficient.  Nothing more is achieved by choosing to store or
incorporate the presentation with the data or vice-versa.

>
> As a legal illiterate, I'm not sure what the real state of play is
> here - but I still think that a list of context-free name/value
> pairs is a pretty shaky basis for a legally binding transaction. -T.

True.  Hence why incorporating the presentation as a participant in the
signature is so important.

But also recognize that not all forms require such a heavy hand of security.
Many forms are used in (closed) environments with a higher level of trust.
Other forms are simply 'worksheets' that facilitate the data entry of data
which is completely self-describing and can be signed on its own.

Some processes do not need to sacrifice the particular aspect of flexibility
that is lost when signing data in concert with presentation -- the
flexibility lost is that the data won't verify in another
presentation...this of course is the primary feature of including the
presentation in the signature, but in some usage contexts this feature is
undesirable.

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN
981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)