[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: XML for forms

  • From: Rob McDougall <RMcDouga@J...>
  • To: "'barclay@u...'" <barclay@u...>, xml-dev@i...
  • Date: Wed, 14 Jul 1999 10:36:36 -0400

presenting xml in 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@u...	       www.uwi.com
>  ===========================================


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



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.