Copyright ©2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
XForms 1.1 is a revision to XForms 1.0 to address immediate needs of the forms community.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the First Public Working Draft of the XForms 1.1 specification. This document has been produced by the W3C XForms Working Group as part of the XForms Activity within the W3C Interaction Domain. The authors of this document are the XForms Working Group participants.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Comments on this document are welcome. Please send issues to the public mailing list www-forms-editor@w3.org. (archive). It is inappropriate to send discussion email to this address. Public discussion may take place on the public mailing list www-forms@w3.org (Archive). Please note that comments that you make will be publicly archived and available, do not send information you would not want to see distributed, such as private data.
This document was produced under the 24 January 2002 CPP as amended by the W3C Patent Policy Transition Procedure. The Working Group maintains a public list of patent disclosures relevant to this document; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) with respect to this specification should disclose the information in accordance with section 6 of the W3C Patent Policy.
1 Introduction
1.1 Reading the Specification
1.2 How the Specification is Organized
1.3 Documentation Conventions
2 XForms Core
2.1 Namespaces for XForms 1.1
2.1.1 No-namespace schema for XForms
1.1
2.1.2 Namespaced schema for XForms
1.1
2.2 Utility Functions used in
XPath Expressions
2.2.1 The power() Function
2.2.2 The luhn() Function
2.2.3 The current() Function
2.2.4 The property() Function
2.2.5 Modification to
Exceptions Generated by Errors in Functions
2.3 Accessing Context Information for
Events
2.4 New Data Type: Email address
2.5 New Data Type: ID Card Number
3 Actions
3.1 The duplicate Action Element
3.1.1 The xforms-duplicate
Event
3.2 The destroy Action Element
3.2.1 The xforms-destroy Event
3.3 The close Action Element
3.3.1 The xforms-close Event
3.4 Modifications to the insert and
delete Actions
3.5 Modifications to Deferred
Update Behavior of Actions
4 Submission
4.1 Improved Targetting of Returned
Data
4.2 New Submission Events
4.2.1 The
xforms-submit-serialize Event
4.3 New Submission Attributes
4.3.1 The validate
attribute on element submission
4.3.2 The relevant
attribute on element submission
4.4 Integration with SOAP
4.4.1 Representation of SOAP
Envelope
4.4.2 Indicating a SOAP
submission
4.4.3 SOAP HTTP Binding
4.4.4 Handling the SOAP
Response
5 User Interface Improvements and Changes
5.1 Inline Rendition of Non-Text Media
Types
5.1.1 The
xforms-output-error Event
5.2 Add UI Common to output
5.3 Remove Linking Attributes from Actions
and Metadata Elements
6 Conformance
6.1 XForms Model
6.2 XForms Namespace
6.3 Incompatibilities between XForms 1.0
and XForms 1.1
A Schema for XForms 1.1
B References
B.1 Normative References
B.2 Informative References
C Changes (Non-Normative)
D Acknowledgements (Non-Normative)
E Production Notes (Non-Normative)
The specification has been written with various modes of presentation in mind. In case of a discrepancy, the online electronic version is considered the authoritative version of the document.
This document uses the terms must, must not, required, shall, shall not, recommended, should, should not, may, and optional in accord with [RFC 2119].
The specification is organized as a set of changes relative to [XForms 1.0]. Chapters are arranged by topic.
Throughout this document, the following namespace prefixes and corresponding namespace identifiers are used:
xforms: The XForms 1.1 namespace (http://www.w3.org/2004/xforms/)
html: The XHTML 2.0 namespace
ev: The XML Events namespace [XML Events]
my: Any user defined namespace
This is only a convention; any namespace prefix may be used in practice.
The following typographical conventions are used to present technical material in this document.
The XML representations of various elements within XForms are presented using the syntax for Abstract Modules in XHTML Modularization [XHTML Modularization].
Examples are set off typographically:
Example Item
References to external documents appear as follows: [Sample Reference] with links to the references section of this document.
The following typesetting convention is used for non-normative commentary:
Note:
A gentle explanation to readers.
Editorial note: Editorial Note Name | |
Editorial commentary, not intended for final publication. |
The XML Schema definition of XForms 1.1 is available in two forms.
XForms 1.1 includes a schema with no target namespace which allows XForms to be incorporated into another namespace using the XML Schema include facility. This kind of schema is sometimes referred to as a Chameleon schema.
<switch> <case id="in" selected="true"> <input ref="yourname"> <label>Please tell me your name</label> <toggle ev:event="DOMActivate" case="out"/> </input> </case> <case id="out" selected="false"> <p>Hello <output ref="yourname" /> <trigger id="editButton"> <label>Edit</label> <toggle ev:event="DOMActivate" case="in"/> </trigger> </p> </case> </switch>
This example is a redefinition of one provided in the XForms 1.0 Recommendation. In XForms 1.0 the <p> element would have required a namespace prefix to indicate that is comes from the XHTML namespace.
XForms 1.1 also includes a schema which has a target namespace specified and as such is compatible with the XForms 1.0 definition. This schema includes all of the no-namespace schema and assigns is a target namespace of http://www.w3.org/2004/xforms/
<switch xmlns="http://www.w3.org/2004/xforms/"> <case id="in" selected="true"> <input ref="yourname"> <label>Please tell me your name</label> <toggle ev:event="DOMActivate" case="out"/> </input> </case> <case id="out" selected="false"> <html:p>Hello <output ref="yourname" /> <trigger id="editButton"> <label>Edit</label> <toggle ev:event="DOMActivate" case="in"/> </trigger> </html:p> </case> </switch>
The above example is unchanged from the specification in XForms 1.0 with
the exception that the new XForms 1.1 namespace is used (in the example, the
prefixes html and ev are defined by an ancestor of the switch
element).
number power(number, number)
Raises the first argument to the power of the second argument, returning
the result. If the calculation does not result in a real number, then
NaN
is returned.
Examples:
power(-1, 0.5)
returns NaN
.
if (prin>0 and dur>0 and rate>0, prin*rate/(1-power(1+rate, -dur)), 0)
returns a compounded interest payment value given a non-zero principal
(prin
), duration (dur
) and periodic interest rate
(rate
).
boolean luhn(string)
If the string parameter conforms to the pattern restriction of the xforms:ID-card-number type, then this
function applies the luhn
formula described in [ISO 7812-1:2000] and returns true if the number
satisfies the formula. Otherwise, false is returned.
Examples (see also 2.5 New Data Type: ID Card Number):
luhn(.)
returns true
if and only if the context node contains a
string that contains 12 to 19 digits and satisfies the formula.
luhn('123')
returns false
.
node-set current()
Returns the context node used to initialize the evaluation of the containing XPath expression.
Examples:
For the following instance data:
<xforms:instance xmlns=""> <converter> <amount>100</amount> <currency>jpy</currency> <convertedAmount></convertedAmount> </converter> </xforms:instance> <xforms:instance xmlns="" id="convTable"> <convTable date="20040212" currency="cdn"> <rate currency="eur">0.59376</rate> <rate currency="mxn">8.37597</rate> <rate currency="jpy">80.23451</rate> <rate currency="usd">0.76138</rate> </convTable> </xforms:instance>
and the following value calculation bind:
<bind nodeset="convertedAmount" calculate="../amount * instance('convTable')/rate[@currency=current()/../currency]"/>
the content value of /converter/convertedAmount
is the
product of /converter/amount
and the conversion table rate given
by the rate
element whose currency
attribute value
matches the content of /converter/currency
.
For the following instance data:
<xforms:instance xmlns="" id="i1"> <months> <mon>01</mon> <mon>02</mon> <mon>03</mon> </months> </xforms:instance> <xforms:instance xmlns="" id="i2"> <months> <month code="01">Jan</month> <month code="02">Feb</month> <month code="03">Mar</month> </months> </xforms:instance>
and the following repeat structure:
<repeat nodeset="mon"> <output value="instance('i2')/month[@code = current()]/> </repeat>
the output should contain Jan Feb Mar
.
string property(string)
This function acts as it did in XForms 1.0 except it returns "1.1" for the version.
Examples:
property("version")
returns 1.1
.
property("conformance-level")
returns full
.
The boolean-from-string() function returns false
when its
string parameter does not match a case-insensitive comparison to the valid
lexical values for an xsd:boolean, rather than halting processing with an
xforms-compute-exception event.
When an error occurs in an XPath function, an xforms-compute-exception
occurs only if the function appears in the expression of a model item
property. When an error occurs in a function that appears in any other XForms
attribute that contains an XPath expression, such as nodeset
,
ref
or at
, then an xforms-binding exception
occurs.
node-set event(string)
Function event
returns context specific information
determined by the string argument. The context information is always
returned as an element node with a local name equal to the parameter name and
no namespace URI.
Each events will describe what properties can be accessed by this
function. The following is a list of the properties accessible with the
XForms 1.0 events (these are all of type xsd:string
):
xforms-insert
, xforms-delete
xform-submit-error
,
xforms-link-exception
, xforms-link-error
,
xforms-compute-exception
Examples:
event("description")
Returns a node with either empty content or, if called from an appropriate event handler, the context information defined for the event (e.g. the path expression used for insert/delete).
event("errorinformation")
If called from an appropriate event handler, the returned node contains the context information (e.g. the URI that failed to load for an xforms-link-exception). The returned node content is empty if there is no context information for the event.
XForms provides support for several built-in datatypes, includes datatypes
derived by restriction, derived by list, and derived by union from these base
types. XForms also defines new derived datatypes that are commonly used in
forms. The following text describes a new derived datatype,
xforms:email
, introduced for XForms 1.1. This datatype
represents an email address, as defined by [RFC 2822]. Internationalized
email addresses are not restricted by XForms beyond the definition in the
RFC. For simplicity, some extremely uncommon features of the RFC syntax are
not allowed, such as "Obsolete Addressing" from section 4.4, square-bracketed
"domain-literal"s, and insignificant whitespace and comments.
Examples of valid xforms:email addresses
editors@example.com
~my_mail+{nospam}$?@sub-domain.example.info
Examples of invalid xforms:email addresses
editors@(this is a comment)example.info
editors{at}example{dot}info
Note:
It is outside the scope of XForms to determine whether a given email address actually corresponds to an active mailbox.
Note:
To be added to the Schema for XForms 1.1--the following datatype:
<xsd:simpleType name="email"> <xsd:restriction base="xsd:string"> <xsd:pattern value="[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+(\.[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~ ]+)*@[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+(\.[A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~]+)*"/> </xsd:restriction> </xsd:simpleType>
The following text is only for discussion in the Working Group, and will be removed before first publication of this document. Since regular expressions aren't a programming language, there's no way to define a common recurring segment, and the regular expression tends to get a little repetitive. Taken one step at a time, however, it makes perfect sense.
The main achievement in this lengthy statement is the definition of what the email address specification calls "atext", which is defined alpha characters, digits, or one of the following characters: "!" "#" "$" "%" "&" "'" "*" "+" "-" "/" "=" "?" "^" "_" "`" "{" "|" "}" "~" In regular expression syntax, the definition for a single character of atext looks like this: [A-Za-z0-9!#-'\*\+\-/=\?\^_`\{-~] . If regular expressions had a way to define a commonly-recurring string, the regular expression might look like this (with spaces added for readability): atext+ (\. atext+)* @ atext+ (\. atext+)* But alas, the actual regular expression needs to repeat the full definition of atext four times, yielding the full definition of the email datatype.
This type defines the basic structure of an ID number that conforms to [ISO 7812-1:2000]. Various ID cards use this
standard as the format for their numbers including those issued by Financial
Institutions for Debit and Credit cards. The ID number is a pattern
restriction on xsd:string
: it must be between 12 and 19 digits
(0 - 9).
:<xsd:simpleType name="ID-card-number"> <xsd:annotation> <xsd:documentation> This type defines an ID number that conforms to ISO/IEC 7812-1:2000 Identification cards -- Identification of issuers -- Part 1: Numbering system. This type does not apply the Luhn checksum algorithm. </xsd:documentation> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:minLength value="12"/> <xsd:maxLength value="19"/> <xsd:pattern value="[0-9]+"/> </xsd:restriction> </xsd:simpleType>
The standard defines the structure of the number as well as how to apply
the Luhn formula to ensure a correct check digit. This type only specifies
the format of the number. The complementary XPath function
luhn()
should be used to validate that the ID number conforms to
the specification.
<xforms:model> <xforms:instance> <payment method="cc" xmlns="http://commerce.example.com/payment"> <number/> <expiry/> </payment> </xforms:instance> <xforms:bind nodeset="number" type="xforms:ID-card-number" constraint="luhn(.)"/> </xforms:model>
This example specifies that the element number
is of the type
ID-card-number
and that to be valid the luhn function must
evaluate to true indicating that check digit is valid.
duplicate
Action ElementThis action is used to clone and insert a subtree from one place in an instance to another place in an instance.
Common attributes: Common, Events, Single Node Binding
Special attributes:
Required XPath expression to determine where to get the structure to clone from.
Optional XPath expresison to determine where to insert the node
The rules for duplicate
processing are as follows:
The structure to be cloned is determined by evaluating the node-set
from the origin
attribute with the same context used for the
single node binding.
The first node in document order is selected from the
origin
node-set. If the node-set is empty or the first node
is either the root node or a namespace node, then the action has no
effect.
The selected node for cloning is now cloned as is defined by the
metode cloneNode
in DOM Level 2 API. This will be the
cloned subtree.
The node which will get the cloned subtree as a child or attribute is determined by the Single Node Binding attributes, this will be the parent node. If the parent node is not a root node or an element node then the action has no effect.
If the before
attribute is present it is evaluated to
determine where to place the cloned subtree. The first node in document
order is selected from the before
node-set and will be the
before node. If that node is not a child of the parent node,
then this action has no effect.
The cloned subtree is now inserted into the instance
by
the following rules:
If the parent node is an element and the cloned subtree an attribute then it will be inserted as an attribute of the parent node. If the parent node has an attribute with the same local name and namespace URI then that attribute is replaced.
If there was no before
attribute or if it
evaluated to an empty node-set, then the cloned node is
appended to the parent node's children.
The cloned subtree is added as a child of the parent node in such a way that the previous sibling of the before node is the top element of the cloned subtree.
If the insertion will make an instance
that is not
well-formed then this action must not have any effect.
If a node was successful inserted into the instance
an
xforms-duplicate
event is dispatched.
Note:
The duplicate
action is subject to deferred processing.
<xforms:instance id="dest"> <persons xmlns=""/> </xforms:instance> <xforms:instance id="proto"> <person xmlns=""> <name>David Landwehr</name> </person> </xforms:instance> <xforms:trigger> <xforms:label>Create new person</xforms:label> <xforms:duplicate ref="instance('dest')" origin="instance('proto')" ev:event="DOMActivate"/> </xforms:trigger>
<xforms:instance id="dest"> <persons xmlns=""> <person> <name>Roland Merrick</name> </person> </persons> </xforms:instance> <xforms:instance id="proto"> <person xmlns=""> <name>David Landwehr</name> </person> </xforms:instance> <xforms:trigger> <xforms:label>Create new person as a first child</xforms:label> <xforms:duplicate ref="instance('dest')" origin="instance('proto')" before="*[1]" ev:event="DOMActivate"/> </xforms:trigger>
<xforms:instance id="dest"> <persons xmlns=""> <person> <name>David Landwehr</name> </person> </persons> </xforms:instance> <xforms:instance id="proto"> <attibutes xmlns="" gender="male"/> </xforms:instance> <xforms:trigger> <xforms:label>Insert a gender attribute</xforms:label> <xforms:duplicate ref="instance('dest')/person" origin="instance('proto')/@gender" ev:event="DOMActivate"/> </xforms:trigger>
xforms-duplicate
EventThis event is dispatched when a successful clone and insert was performed
on an node in an instance
by the duplicate
action.
instance
Yes
No
The following properties are accessible from the
event()
function:
The parent of the node which received the new node.
The before node
The node which was used to make the cloned subtree
The top element of the cloned subtree
The default action for this event results in the following: None; notification event only.
destroy
Action ElementThe destroy action is used to delete a node from the instance.
Common attributes: Common, Events, Single Node Binding
This action is used to remove nodes from the instance.
The rules for destroy
processing are as follows:
The node to delete is selected from the Single Node Binding attributes.
If the node is a root node or a namespace node then the action has no effect otherwise the node is removed from the instance.
If a node was successful removed from the instance an
xforms-destroy
event is dispatched.
Note:
The destroy
action is subject to deferred processing.
<xforms:instance> <data xmlns=""><element>Value</element></data> </xforms:instance> <xforms:bind nodeset="element" id="element"/> <xforms:trigger> <xforms:label>Delete element</xforms:label> <xforms:destroy ev:event="DOMActivate" bind="element"/> </xforms:trigger>
<xforms:instance> <data xmlns="" attr="Value"/> </xforms:instance> <xforms:trigger> <xforms:label>Delete attribute</xforms:label> <xforms:destroy ev:event="DOMActivate" ref="@attr"/> </xforms:trigger>
xforms-destroy
EventThis event is dispatched when a successful delete was performed on an node
in an instance
by the destroy
action.
instance
Yes
No
The following properties are accessible from the
event()
function:
The parent of the deleted node.
The node which were deleted.
The default action for this event results in the following: None; notification event only.
close
Action ElementThis action is used to dispatch an xforms-close
event to a
model.
Common attributes: Common, Events
Special attributes: None
Dispatches an xforms-close
event to the default model.
<trigger> <close ev:event="DOMActivate"/> </trigger>
xforms-close
EventThis event, dispatched to the default model element, results in closing down the owner document. In a rendering environment, this may close downt the user agent that renders the document.
model
Yes
Yes
None.
The default action for this event results in the following: Close down the owner document.
insert
and delete
ActionsIn XForms 1.1, the insert
action behaves as in XForms 1.0
except that the prototype for the instance data to be inserted is obtained
from the live instance DOM rather than from initialization instance data.
Specifically, the source of the prototype is obtained by evaluating the
nodeset
against the current instance DOM, then choosing the node
indicated by the attribute at
.
In XForms 1.0, the delete
action has no effect if the
homogeneous collection indicated by the nodeset
attribute is
empty. In XForms 1.1, the delete
action also has no effect if
the homogeneous collection contains only one node. This restriction is
necessary because an homogeneous collection that becomes empty no longer has
prototypical data needed to perform future insert
actions.
It is recommended that form authors precede a delete action with
setvalue
actions that clear the data to empty values so that
deleting the only member of an homogeneous collection appears to the end-user
as if the member has been cleared. Alternately, it is recommended that form
authors use the duplicate
and destroy
actions to
manipulate homogeneous collections.
TBD
In XForms 1.0, the deferred update behavior would choose to run rebuild, recalculate, revalidate and refresh actions directly, bypassing the event system. In XForms 1.1, the events are dispatched as needed.
The detection of the need for deferred update is managed at the level of the XForms model. When XForms action B runs as the result of another XForms action A, then the deferred update behavior of B is further deferred to the completion of A, regardless of whether B is a descendant of A in the XML markup.
In XForms 1.0, the target of XML data returned by a submission with
replace="instance" was the same from which the instance was drawn. We now
want the returned XML data to be able to be placed in an alternate instance.
The submission
element must allow a new optional attribute
called instance
of type IDREF. If given, this attribute
indicates the instance to be replaced with the XML data returned from the
submission.
An anticipated use of this attribute is to target a returned SOAP envelope
at a scratch instance. The form author can then catch the
xforms-submit-done
event and use XForms actions to copy the
underlying payload to one or more data instance nodes.
Dispatched by the processor immediately before serializing the instance data for submission (immediately before step 3, Section 11.1, XForms 1.0).
Target: submission
Bubbles: Yes
Cancelable: No
Context Info: A node into which data to be submitted can be placed.
The default action for this event is to perform the normal XForms submission serialization if the event context node's content is empty. The content of the event context node is the data sent by the XForms submission.
The submission
element must allow a new optional attribute
named validate
of type boolean. The default value is
true
.
If the value of attribute validate
is true
then
the processing of a submission is unchanged from XForms 1.0, i.e. the
instance being submitted must be valid for processing to proceed.
If the value of attribute validate
is false
then
the processing of a submission is changed from XForms 1.0 in the following
way. The instance will still be validated according to the rules defined for
the xforms-revalidate
event but an
xforms-submit-error
will not be dispatched if there is a
validation error allowing submission processing to proceed.
The submission
element must allow a new optional attribute
named relevant
of type boolean. The default value is
true
.
If the value of attribute relevant
is true
then
the processing of a submission is unchanged from XForms 1.0, i.e. the
instance being submitted will not contain instance data nodes whose model
item property relevant
evaluates to false()
.
If the value of attribute validate
is false
then
the processing of a submission is changed from XForms 1.0 in the following
way. When the instance is serialized it will contain all selected instance
data nodes, including instance data nodes whose model item property
relevant
evaluates to false()
.
The single-node binding of the submission
element refers to
the XML data to be submitted. In the case of a SOAP submission, the instance
data includes the SOAP envelope and related SOAP tags.
Note:
The form author may choose to store the data payload in one instance and
copy the data to the submission instance containing the SOAP envelope as part
of an xforms-submit
event handler. The form author is
responsible for declaring the appropriate model item properties on both
instances (e.g. the relevant
declarations).
For a SOAP submission, the mediatype
attribute of the
submission
must be set to
the MIME type of application/soap+xml
. The form author may
append charset
and action
MIME parameters.
Note:
The action
MIME parameter has no effect unless the submission
method
is "post" because the GET method implies no SOAP
processing by the receiving SOAP node.
Note:
SOAP 1.1 does not support the HTTP GET operation.
The method
attribute of the submission
must be set to get
or
post
in order to access the SOAP HTTP binding, which results in
the use of the application/xml
serialization rules.
If method="get"
, then the SOAP response message exchange
pattern is used. The HTTP headers must
contain the Accept parameter with a value conforming to the following
properties:
must begin with
application/soap+xml
If the submission mediatype
contains a
charset
MIME parameter, then it is appended to the The
application/soap+xml
MIME type
No other MIME parameters from the mediatype
are copied
to the application/soap+xml
MIME type
The q
MIME parameter must not be specified in the
application/soap+xml
MIME type so that the default quality
of 1 is used.
If method="post"
, then the SOAP request-response message
exchange pattern is used. For SOAP 1.2, the current submission behavior of
using the mediatype
attribute value as the value of the
ContentType parameter in the HTTP headers is sufficient. If the instance data
being submitted has as its root element node a SOAP envelope in the SOAP 1.1
namespace (http://schemas.xmlsoap.org/soap/envelope/
), then:
the ContentType HTTP header is change to text/xml
the charset
MIME parameter is appended if it was
specified in the mediatype
if the action
MIME parameter appears in the
mediatype
then a SOAPAction HTTP header is added and given a
value equal to the content of the action
MIME parameter
Note:
XForms 1.1 does not support the SOAP email binding, so method="post" with
a mailto:
scheme results in an xforms-submit-error
event before any submit processing message is dispatched.
Note:
XForms 1.1 does not support the SOAP 1.1 binding to the HTTP Extension Framework.
The XForms processor must handle client authorization and redirection.
SOAP faults (400 and 500 level errors) are handled in the same manner as
underlying HTTP errors, which is to say that an
xforms-submit-error
event is dispatched.
On successful completion, the results are consumed according to the XForms
submission process, culminating in an xforms-submit-done
event.
The form author may capture this event and copy data from the target instance
that receives the returned SOAP envelope to other instances that are designed
to carry only data.
In XForms 1.0, the output
element can take a single node
binding indicating an instance node whose textual content is to be rendered
inline. In XForms 1.1, the content model of the output
element
is enhanced to allow the specification of a mediatype
attribute
or a mediatype
child element.
The mediatype
attribute and mediatype
child
element are ignored unless the output
has a single node binding
that resolves to an instance node with non-empty content.
When both the mediatype
attribute and the
mediatype
element are given, the attribute takes precedence.
When the mediatype
element has both content and a single node
binding, the single node binding takes precedence. When neither the
mediatype
attribute nor the mediatype
element are
given, the output
behaves as in XForms 1.0, rendering inline the
text content of an identified instance node.
The mediatype
attribute or element indicates the desired type
of media rendition that should be
performed if it is possible to do so (e.g. a voice-only device cannot render
a digital image). The desired rendition type is indicated by a string value,
such as image/*
or image/png
, in the
mediatype
attribute value, the content of the node referenced by
the mediatype
element, or the mediatype
element
content.
If the mediatype
attribute or element is given, then the
instance node indicated by the single node binding must be decoded or dereferenced prior to rendition
based on schema or XForms data type. An instance node of type
xsd:base64Binary
or xsd:hexBinary
is decoded, and
an instance node of type xsd:anyURI
is dereferenced.
The rendition of the output
is updated if the referenced node
or its content or if the media type changes. The media type can change due to
DOM mutation of the content of the mediatype
attribute or
element or by a change to the mediatype
element's referenced
node or its content.
Failure to render the content indicated by the output
element
should result in an
xforms-output-error
, a non-fatal error that does not halt XForms
processing. Failures can occur for many reasons, including
Data incorrectly identified as xsd:base64Binary
or
xsd:hexBinary
An xforms-link-error
dereferencing a node of type
xsd:anyURI
A data format error (e.g. invalid or unsupported image format)
An unrecognized media type identifier string
Dispatched by the processor immediately after the first failure of an
output
to render or update the rendition of content.
Target: output
Bubbles: Yes
Cancelable: No
Context Info: None.
The default action for this event is nothing; notification event only.
Since the output
element can be the target of the
xforms-output-error
, the content model for the
output
is opened further to include XForms actions.
XForms elements may be used in the namespace declared in this specification. However, the XForms namespace is designed to be a chameleon namespace that allows XForms elements to be imported into a host language. Therefore, an XForms processor should allow parameterization of the namespace URI. Any element with a local name of an elements defined by XForms would then be recognized for XForms processing if the element's namespace URI also matched the URI parameter provided to the XForms processor.
While many XForms 1.0 forms will operate as originally intended when migrated to an XForms 1.1 processor by simply redefining the xforms prefix to be the namespace URI of XForms 1.1, there are some behavioral changes that have been made to elements and features that existed in XForms 1.0. Therefore, some XForms 1.0 forms will require some adjustments beyond simply changing the namespace URI.
This document was produced with the participation of current XForms Working Group participants: