View source for Submission some kind of better filtering than relevance that affects only submission and not the UI

__NOTOC__
[[LeighKlotz]], [[MarkBirbeck]] to start.

= Use Cases =
== Delete mail messages ==
Consider an instance representing a list &lt;messages&gt;, of email &lt;message&gt; each with a @selected and a @message-id, a &lt;subject&gt; and other headers, and a &lt;body&gt;.  The body content is potentially large.  The messages can be displayed with a repeat. When the users wishes to delete the current message, a POST would send just the @message-id; however, when the user wishes to delete multiple messages, we have no mechanism to submit just the &lt;messages&gt;, &lt;message&gt; and @message-id structure for each &lt;message&gt; that is @selected.  (There is an additional problem if the message data doesn't initially include @selected, in which case the Shadow Instance proposal may solve both.)

=== Current Workaround: Use bind/@relevant with a boolean in a second instance ===
Set the boolean during xforms-submit and reset on xforms-submit-done or xforms-submit-error.
Use the boolean in the relevant expressions so that the data is relevant during view but not relevant during submit.
Problem: Unless you catch refresh, this causes the UI to jump around.  It's also painful to write.

=== Proposed Solution: Shadow Instance ===
[[Templates of shadow data]] to create a separate instance containing only the selected messages, and to contain a made-up @selected if necessary.

=== Proposed Solution: @nodeset on submission ===
Allow a nodeset instead of a ref on submission, and submit the resulting nodes. 
Problem: What is the root element?  How do you do the union to get the structure?

== Don't submit empty elements ==
We have the required model item property to tell the processor not to submit the instance if the them element or attribute is empty, but no way to tell the processor not to submit the element or attribute itself if empty. 
References: [http://xforms.org/pipermail/xforms_dev_xforms.org/2007-March/000016.html xforms.org mail thread]
[http://xforms.org/pipermail/xforms_dev_xforms.org/2007-March/000017.html xforms.org mail thread]

=== Current Workaround: Use bind/@relevant with a boolean in a second instance ===
Set the boolean during xforms-submit and reset on xforms-submit-done or xforms-submit-error.
Use the boolean in the relevant expressions so that the data is relevant during view but not relevant during submit.
Problem: Unless you catch refresh, this causes the UI to jump around.  It's also painful to write.

=== Proposed Soluition: model item property optional ===
Complement the required model item property with an optional model item property, and redefine elements to be tristate with regards to require/optional.  (CSS already supports this view; all their properties are tri-state.)  Required elements or attributes would then cause submission to fail.  No declaration would be current behavior. Optional elements or attributes would be elided if empty.

Problem: We need to define empty more rigorously, especially for elements with complex content.  If an element with element children is marked optional, some people want the entire tree pruned if all child elements are empty, but the entire tree submitted if any child element is non-empty (where empty is defined as non-whitespace text).  Others want each individual element under the bound node to be pruned based on its own state.

Problem: We need to decide what happens if both required and optional are true.  Do we need to re-examine relevant and readonly as well to see if tri-stating makes sense there?

== Use case: Arbitrary Transformation ==
We put this whole issue off for XForms 1.0 because we felt that arbitrary transformation was best done with XSLT.
Has any processor hooked XSLT into the submission mechanism?  It seems like there may be room for that and still room for a solution for common use cases, which we should explore above.

=== Proposed Solutions ===