RE: XFoms "suspend and resume" support

Hello Stéphane,

I understand and agree with all the use cases you list. All of them are
valid, but an additional question is: WHY is it necessary in an
interoperability specification to define this behaviour? HTML does not
define a "save as" menu option, still most if not all current browsers
implement one.

One way to look at standardization is that we specify what happens at
the boundary between two systems. In the case of XForms, that is one (or
more) server sending a form to clients. Is it really necessary to
standardize a local suspend, or is it in the realm of the individual
vendor? Is it really necessary to standardize a remote suspend? Today,
XForms defines only what happens on the client - with a remote suspend
feature, we would have to touch the server, too. Is it worth it, or can
we leave this to implementors?

Whatever is saved, chances are that it is available as a well-formed XML
instance somewhere, so even loading it into a different client would
hardly be a problem. The only potential trouble is if the
state-to-be-stored does not satisfy the model constraints.

regards,

Josef

> -----Original Message-----
> From: CULANG Stéphane [mailto:Stephane.CULANG@France-boissons.fr]
> Sent: Friday, September 21, 2001 4:16 PM
> To: www-forms@w3.org
> Subject: XFoms "suspend and resume" support
> 
> 
> 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 ?
> 
> 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 Friday, 21 September 2001 10:51:16 UTC