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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: XML for forms

[ Lists Home | Date Index | Thread Index ]
  • From: "Barclay Blair" <barclay@uwi.com>
  • To: "Gavin McKenzie" <gmckenzi@JetForm.com>, "'Tim Bray'" <tbray@textuality.com>, "'David Megginson'" <david@megginson.com>, <xml-dev@ic.ac.uk>
  • Date: Tue, 13 Jul 1999 14:21:26 -0700

Gavin,

I'm interested to know from where you are deriving your opinion that
"persisting presentation and data together isn't required or necessary,"
when legal experts have stated differently.  I'd been interested in any
information that you could provide from legal experts who say that it is
better, or even good practice, to separate the questions and answers of
a form.

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:31 PM
To: 'Tim Bray'; 'David Megginson'; 'xml-dev@ic.ac.uk'
Subject: RE: XML for forms



Ooops...pardon me, something unfortunate has just been brought to my
attention.

> Tim Bray wrote:
> > 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).

Gavin McKenzie wrote:
> Sign yes. Include no.  It requires that content (data) and


My comments might lead somebody to believe that I am attempting to clarify
the position of XFDL -- if it isn't already obvious from the domain of my
email address, I am doing no such thing -- obviously based on my previous
emails I have a professional bias on this topic towards the body of work
known as XFA.  I am speaking for my own opinions and the XFA specifications.

When I said, "It requires that..." I was not speaking of XFDL, which I
cannot speak for.  Rather, I was generally stating that "Non-repudiation
(often) requires that the context and presentation be signed...".

People (customers) have a wide range of requirements that are not best
served by a single simple solution.  Persisting presentation and data
together isn't required or necessary.

> 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)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS