W3C home > Mailing lists > Public > www-forms-editor@w3.org > November 2002

Evolving Instance submission protocol

From: Karandikar, Shailesh <Shailesh.Karandikar@dendrite.com>
Date: Fri, 15 Nov 2002 12:55:23 -0500
Message-ID: <2EFF7C1E3711D4119327009027D767F80C3EAE5F@DIEXCLNT>
To: "'www-forms-editor@w3.org'" <www-forms-editor@w3.org>


[ Note : I've already tried sending this mail to www-forms@w3.org. Didn't
see it in the list. So, decided to redirect it to www-forms-editor@w3.org
with minor changes]

A question on handling deletes for repeat nodes.
Consider a case where a few nodes are deleted from the instance, which were
not inserted during the current user interaction. 

When user submits a form with a valid instance, the receiving application
doesn't explicitly know that certain nodes were deleted. 
It must perform some comparison with the original instance to figure that
one out, which may not be that easy/efficient/robust.

So, lets imagine that the processor also submits deleted nodes (let us say
marked with some status), along with the modified instance. But then, 
the resulting instance may not be valid according to the model constraints,
because these additional nodes are present.

This problem doesn't arise when one is submitting new instances fragments.

So, we need a standard/declarative way to tell XForms receiver how/where to
look for this information.
A potential solution would be to use protocols like XQuery update in future
or Updatagrams, etc.to submit changed data, or something like
XForms-submission protocol.

Although submission model element tries to use various attributes to specify
how and what fragment gets submitted, we don't have an agreed upon mechanism
to convey above information. 

I'm aware of the fact that presently there is no universally agreed upon way
to specify Xml updates; However, XForms WG could take up this initiative.

Any comments on this issue (unless I've missed some things completely) are

Shailesh Karandikar
R&D Dendrite.
Received on Friday, 15 November 2002 13:00:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:25:05 UTC