Background

The load element uses the @show attribute from XLink and allows show='new' and show='replace'.

The submission element has @replace attribute with values replace="all" replace="none" and replace="instance".

It would be good to have the show="new" feature from load.

It would also be good to have the show="embed" proposed feature from Load Embedding

So perhaps submission/@show="replace" and load/show="new" should be unified.

Prior discussion leaned toward use of a target attribute, available only in the replace="all" case. (It is for this reason that we renamed the XForms 1.0 submission/@target to submission/@targetref.) The host language would be responsible for resolving target attribute values. For example, in an XHTML+XForms integration, with submission/@target="_blank" the submission result would go to a new window.

We also discussed using a fragment id as in target="#id"for targeting the content of an element in the current page.

Discussion of a new replace="new" option

During the June 2 and June 9, 2010 calls, we discussed the use of replace="new". Arguments in favor of this proposal:

XForms 1.1 says that when replace="all" completes successfully, the whole containing document is replaced. See 11.2 The xforms-submit Event.
The proposed @target attribute on xforms:submission is meant (in general) to open the response body in a new window .
So in order to avoid changing the semantic of replace="all" based on the presence of @target, replace="new" is desired.
The result would be that:
- replace="new" would work alongside @target and would clearly indicate that the response is opened in a new window
- replace="all" would clearly indicate that the response replaces the current containing document

However, the group has established that the above doesn't hold:

Current user agents, upon receiving a response, do not necessarily replace the current document in the absence of a @target. They may:
- replace the current document with the response document
- open the response document with an application
- download the response document
The above is usually not under form author control, because the user agent might make that decision based on factors such as:
- the response content type
- a response Content-Disposition header
- plugins currently installed in the user agent
So replace="all" in current implementations does not necessarily replace the current document.

In addition:

replace="new" with target="_self", for example, and a returned HTML document without Content-Disposition, would typically result in replacing the current containing document.

In light of the above:

replace="new" would not make things clearer to form authors.
We don't think that a @target attribute would change the semantic of replace="all" in current implementations.

Proposed solution:

We do not add replace="new".
The spec needs to be clarified.

Proposed clarifications:

Section 11.2 must not say that "submit processing concludes with entire containing document being replaced with the returned body", as that might not be the case.
Instead we provide implementor and author guidance.
With replace="all" and no target, the following might happen:
- The containing document may or may not be replaced depending on user agent policies.
- The response document may instead be downloaded or open by the user agent in another way (external app or plugin).
- The user agent typically uses the response content type and headers such as Content-Disposition, but possibly other configurations, to make this decision.
With replace="all" and a target attribute, the following might happen:
- If the target value points to the current window (e.g. "_self"), this is the same as the absence of @target.
- If the target value points to another window (e.g. "_blank" or custom window ids), the current document is most likely not replaced. The user agent might:
  - open the response body in a new window
  - initiate a download

We might be more or less specific on guidance, and instead opt for saying that the exact behavior is user agent dependent.

Issues

Download

The Orbeon output/@appearance=xxforms:download approach is compliant with the XForms 1.1 extension mechanism, but not what the WG wants to pursue, so we are considering adding the Download feature to submission (and load, by proposed equivalence).

There are implementation concerns with HTML4 user agents:

In HTTP, if Content-Disposition: Attachment is specified, HTML4 desktop browsers might bypass the submission response handling anyway
HTML4 browsers and they also might have difficulty forcing the save option if Content-Disposition: Attachment isn't specified.
Split-agent (server-side) solutions can combine these two "problems" to implement the feature, and plug-ins might be able to work as well, but JavaScript client-side implementations might or might not be able to.

In [1] we decided to pursue this issue as replace='file' but have not resolved whether to include it as a Recommended feature in XForms 1.2.

Previous Discussion and Implementations

Related Issues

Load Embedding