RE: XFoms "suspend and resume" support

Another point to consider:

We've built extensibility into the <submitInfo> element--implementations can
provide alternate ways of delivering the data, including offline-compatible
protocols, for instance SOAP over email.

This would, of course, be outside the spec. But if lots of people use it
anyway, then it will probably get noticed for XForms future-version
consideration.

Thanks!

.micah

-----Original Message-----
From: joern turner [mailto:joern.turner@web.de]
Sent: Friday, September 21, 2001 2:55 PM
To: CULANG Stéphane
Cc: www-forms@w3.org
Subject: Re: XFoms "suspend and resume" support


Hello Stéphane,

i absolutely agree that offline use may be of great interest for many 
applications. but it could also be a advantage if the standard does not 
try to address all possible issues for every system environment/usage. 
these standard are often hard to implement and i would like to see a 
XForms processor as a component (like a bean) with clearly defined 
interfaces to its container-application.

there are already some (evolving) standards dealing with some of these 
issues (see below).

but it may also be of interest to investigate if there are some pieces 
missing in the current spec, especially in the area of interfacing with 
external systems / remote servers. the interfaces should be rich enough 
to exchange the relevant information between a client and the server.

CULANG Stéphane wrote:

> Hello,
> 
> Xforms should not get restricted to online use.
> 
> I agree that many browsers like mobile phones cannot store local
information
> but it is also true that most people using computers, laptops or pdas
cannot
> remain online forever to do their work. ISDN, ADSL or cable connexions are
> still a dream for most people in the world and will remain so for a long
> time. Mobile internet on wireless devices with decent bandwith is still
> years away, mostly due to price considerations. 
> 
> Limiting Xform to online use also limits the scope of its application. As
> soon as a complex form requires a substantial amount of time to complete,
> you loose many benefits of the Xform technology. For instance, an example
of
> suspend usage depicted in some article was taxpaying forms. Filling one of
> these online, connected with a connexion you pay according to the time it
> lasts may cost close to the calculated tax amount :-).
> 
> The idea of a document you can keep with you indefinitly and submit when
its
> done and/or when you have access to a network POP was so elegant and so
> close to real world needs that I dont easily understand why it's about to
be
> droped after the w3c has gone so far with it's superb XML specification
and
> associated standards.
> 
> I agree about the security issues associated with online suspended forms.
> Some of them seem impossible to achieve. For instance, would it be
possible
> to deny access to a suspended form saved online, to any user except the
one
> that suspended it ? How the form is supposed to locate the suspended
> instance instead of the original unmodified one that any "new" user would
> load. When resuming the form, how would the specific instance associated
to
> a user session get resumed ?



there are already standards (or at least working groups) dealing with XML
Signature

and encryption (see w3c homepage - i unfortunately don't remember the 
exact name). the idea is to simply sign a XML document with a hash based 
on the content of the document + your private key (public/private key 
encryption) and use this key to sign and encrypt the document.

this would allow a server secure authentication/authorization for the 
resumed instance-data.
---

maybe this is one little gap....
how should the instance-data be associated with the form which produced 
them?

under time-pressure we've implemented a solution which works quite fine:
we simply defined an href-attribute on the xform:instance node in our 
own namspace (that's the wonderful about XML).

through a very simple interface based on the XLink roles defined by 
XForms we can identify the type of requested data (container, model, 
instance, UI, external data-list) and the implementing 
(application-specific) connector classes can resolve the hrefs on 
instances and load the appropriate form to display/edit them.


Joern Turner


> It should be much easier to implement a local temporary storage because
you
> can always secure a single workstation and its file system, the xform
would
> always open the same instance file in its original or suspended state.

> 
> For our corporate use, we'll want to store xfoms and xml data on laptops
for
> our salesmen to carry to their clients store and take orders. Most of
their
> work is done disconnected so, if the functionnality is actually dropped, I
> think we'll have to implement some extra software such as a local http
> server with some CGI script to handle a POST of the XML instance data and
> save it locally ... 

> 
> Regards.
> 
> 
> Stéphane Culang
> Architecte technique - ORVIS
> 0147144975
> stephane.culang@france-boissons.fr
> 
> 
>

Received on Saturday, 22 September 2001 19:21:42 UTC