XML for forms
RMcDouga at JetForm.com
Wed Jul 14 16:40:55 BST 1999
>>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
is sufficient to determine if the correct presentation is being subsequently
>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
>>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
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
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
>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.
> 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;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev