XML for forms

[Barclay Blair]

Rob and Gavin,

Thanks for the responses -- very interesting! I always enjoy exchanging
ideas  (or barbs, as the case may be, Gavin :)).  I have some concerns that
we're in danger of boring the rest of the group with the semantics of form
presentation etc., so I'd be happy to continue the discussion individually
with each of you, instead of on the list. That is, unless the group or
yourselves feel strongly about continuing the dialogue on the list.

Thanks,

Barclay

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

-----Original Message-----
From: owner-xml-dev at ic.ac.uk [mailto:owner-xml-dev at ic.ac.uk]On Behalf Of
Rob McDougall
Sent: Wednesday, July 14, 1999 7:37 AM
To: 'barclay at uwi.com'; xml-dev at ic.ac.uk
Subject: RE: XML for forms




>>Yes, the signing of a form must include the presentation and the content,
but no, the two do not need to be persisted together.
>>The signature (which can include the presentation's fingerprint) + the
data
is sufficient to determine if the correct presentation is being subsequently
used.
>According to whom?
>Rob, what exactly do you mean by a "presentation fingerprint" here? How is
this bound to the data and structure of the record?

This is just common sense.  While clearly the signature must include
presentation, because as (I believe) we both agree "a user signs the
presentation", that does not imply that the three parts (content, signature,
and presentation) must be persisted into a single object.  They can be
persisted separately, so long as the three are re-united for the
verification of the signature.

By storing them separately, one doesn't have to duplicate the presentation
over and over again with each filled in form.  This can have enormous
savings in disk space, network bandwidth, CPU usage, etc. when manipulating
the information.


>>If the signature includes the presentation in its digest then it will not
verify with a different presentation.
>The issue here is whether or not an independent third party can verify the
exact state of the data, presentation, and structure (the components
necessary to create a binding record) at the time the user applied the
signature.

Yes absolutely, but please explain to me why persisting these three things
together as one object is a requirement.  As long as the three can be
recombined to create the object that the user signed then there is no
requirement to persist them all as one object.

>I'm not totally clear on what you mean when you talk about "a different
presentation."  If you are talking about presenting the same data in
multiple formats, then you are actually talking about presenting multiple
documents.  If this is the case, then each different "view" needs to be
treated as a different document.
>If you refer back to the Cohasset document I pointed out, you will see that
it touches on concepts that are well defined by organizations like AIIM.
These guidelines state that even small alterations in the appearance of a
document can seriously alter its legal weight.  I would encourage you to
check this information out.

I've read this document and while I agree with many of the assertions they
make, there's one leap of logic that I cannot stomach however.  In the
"Electronic Forms Package" section, they basically say that e-forms systems
that store the presentation and content separately "can maintain this link
[between the presentation and content] for only a short period of time".
This patently false.  This linkage can be maintained for the life of the
document.

A trivial example of what Gavin and I are on about would be a CD-ROM that
contains many instances of signed XML content and one instance of the
presentation medium (say, an XSL stylesheet).  The linkage between the
content and the presentation is permanent and the savings from not having to
store many redundant copies of the stylesheet within the content are (I
hope) obvious to all.  If the signature is constructed to include both the
content and the stylesheet, then the signature will not verify a different
stylesheet.  Voila!  The presentation and content are stored separately, yet
you have the ability to reconstruct the document exactly as signed.  I think
you'll have a hard time finding someone who questions its legal validity.

Obviously, I have problems with the last section in the Cohasset document as
well, but I'm probably biased :).

>>One can persist the data and presentation separately with all the
attendant
savings.
>What type of savings are you referring to?

In the example above, disk space on the CD-ROM is saved.  If you're moving
these objects around your network, bandwidth is saved.  If you're reading
many sets of content into a single form, CPU is saved.  Need I go on?


>>Were these legal agents you speak of apprised of this option?
>Systems that keep document templates and data in separate places have been
around for ages, so I would guess that they were aware of them.

Apparently not.


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


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following
message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at 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 at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)