[
Lists Home |
Date Index |
Thread Index
]
Just noticed an inaccuracy in the document from which I copy/pasted.
Please change:
[goes on to discuss SVG and XML as examples]
to:
[goes on to discuss SVG and XSL as examples]
Chiusano Joseph wrote:
>
> <Quote>
> I would be interested to know what this organisation had in mind when
> using the terms "presentation", "content" and "context".
> </Quote>
>
> I should respectfully clarify that this was not an organization, but a
> federal-sponsored pilot comprised of federal employees,
> contractors/consultants, and vendors (such as Adobe and PureEdge)
> getting together to study issues related to e-forms.
>
> Here is more information on the terms, from a document that was produced
> by the Security subteam of the pilot:
>
> <Terms>
> PRESENTATION:
> The presentation describes how the XML data will be presented to the
> user and rendered on the user's device. It may also define the user
> experience of the interactive elements of the form.
> [goes on to discuss SVG and XML as examples]
>
> CONTENT:
> The data content of the form is provided by the application or a user.
> >From a security perspective there are three types of content, based on
> the degree of cryptographic protection;
> [goes on to describe unsigned, signed, and encrypted content]
>
> CONTEXT:
> The context is any information deemed necessary by the application that
> needs to be stored with the content to assist in its interpretation or
> to ensure the document is trustworthy (when this is needed). This may
> include information such as the role the user held during the session,
> the assurance level assigned to the issuer of the user's credentials,
> the jurisdiction in which the user was deemed to be operating, the
> source of the authority the user as deemed to have invoked, etc.
> </Terms>
>
> More on context, from the U.S. Department of Justice document "Legal
> Considerations in Designing and Implementing Electronic Processes - A
> Guide for Federal Agencies" (November 2000[1]):
>
> <DOJDocument>
> "The legal significance of context surrounding the collection or
> creation of electronic information"
>
> Any information collection system should provide a means to define,
> limit and show the context of the information supplied to the extent it
> is necessary for a particular transaction. For example, a "form" to be
> filled out may require specified information to be supplied on
> particular lines or in boxes, and such forms usually are accompanied by
> explanatory instructions. Completed paper forms include a means of
> identifying not only the answers, but also the questions and
> instructions. The meaning of the answers is evident from the document
> itself.
>
> Electronic processes that use "forms" generally display a template of
> the form to the person filling it out. The person enters the
> information requested by the form. If the system is designed to retain
> and reproduce only the answers, and not the questions or instructions,
> disputes may arise over the meaning of the information supplied.
> Knowing an answer without knowing the corresponding question is of
> little value. Electronic submission systems generally should be
> designed to provide a copy of the form (including all questions and
> instructions) in response to which information was supplied to the
> agency, or bind the form to the answers provided. If an agency's forms
> change over time, and the information on the form is important either to
> the underlying transaction or to an agency process or program, then the
> electronic process should be designed to keep track of the exact form
> used by each submitter of information.
> </DOJDocument>
>
> Kind Regards,
> Joe Chiusano
> Booz | Allen | Hamilton
>
> [1] http://www.cybercrime.gov/eprocess.htm#IIC1
>
> Mark Seaborne wrote:
> >
> > This is the kind of scenario that John has outlined on the XForms list, and for which both InfoPath and XForms appear to be lacking at present.
> >
> > I would be interested to know what this organisation had in mind when using the terms "presentation", "content" and "context".
> >
> > All the best
> >
> > Mark
> >
> > The information in this email is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.
> >
> > Origo Services Ltd accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or the contents.
> >
> > > -----Original Message-----
> > > From: Chiusano Joseph [mailto:chiusano_joseph@bah.com]
> > > Sent: 29 October 2003 13:52
> > > To: Mark Seaborne
> > > Cc: Michael Champion; xml-dev@lists.xml.org
> > > Subject: Re: [xml-dev] InfoPath Digital Signature controversy?
> > >
> > >
> > > Earlier this year, the U.S. Federal CIO Council conducted an "E-Forms
> > > for E-Gov" pilot in which I participated (PureEdge did as
> > > well). One of
> > > the points that was brought out in Section 6.7 (Archival
> > > Records Domain)
> > > of the final report [1] was the importance of binding together
> > > presentation, content, and context:
> > >
> > > <Quote>
> > > Briefly, the National Archives and Records Administration (NARA)
> > > guidlines require that the "presentation", "content", and
> > > "context" must
> > > be bound together in such a way that they can be demonstrated
> > > to belong
> > > to the same transaction. This may mean physically combining
> > > these into a
> > > single physical file, or ensuring that they are bound together through
> > > some other trusted means, such as electronic hashes and signatures. In
> > > addition, any signature must be applied to this combination of
> > > presentation, content, and context, and the authentication
> > > process must
> > > ensure integrity.
> > >
> > > For most government applications, E-Forms solutions must be
> > > designed and
> > > selected with these core archival requirements in mind.
> > > </Quote>
> > >
> > > Kind Regards,
> > > Joe Chiusano
> > > Booz | Allen | Hamilton
> > >
> > > [1] http://www.fenestra.com/eforms/deliverables/final_report.htm
>
> ------------------------------------------------------------------------
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
begin:vcard
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard
|
