%ents; ]>
Form Discovery and Publishing This specification describes a series of conventions that allow the management of form templates and publishing of completed forms. &LEGALNOTICE; 0346 Deferred Standards Track Standards Council XMPP Core XEP-0001 XEP-0004 XEP-0030 XEP-0060 NOT_YET_ASSIGNED &ksmithisode; 0.2 2017-09-11 XEP Editor (jwi) Defer due to lack of activity. 0.1 2014-04-10 editor (mam)

Initial published version approved by XMPP Council.

 0.0.1 2014-04-07 ks

First draft.

There are many circumstances in which it is necessary for entities to 'fill out forms' to be consumed by other entities (such an example might be for reporting an accident in the workplace). This document provides a method by which an entity can discover which forms are available, fetch the templates and submit the completed forms, using standard XMPP &xep0060;.

This is achieved by every form having a pair of pubsub nodes on the same service; one of the nodes contains the template form (the empty form that is to be completed) and the other is used for publishing completed forms.

Pubsub nodes used for these forms are comprised of a standard prefix and an application-specific suffix. Templates and completed forms for the same form type have the same application-specific suffix, but a different prefix. The prefix for form templates is "&templatePrefix;/" and for completed forms is "&completedPrefix;/".

The application-specific suffix must be guaranteed to be unique to the application, so it is suggested to start with a domain under the application author's control; as such if Isode Ltd. were to use this approach for feedback on the Christmas party, a node ID might be formed as "&templatePrefix;/isode.com/christmas-party-feedback/2013" to contain the form template and "&completedPrefix;/isode.com/christmas-party-feedback/2013" for the submitted nodes.

To find the templates present on a pubsub service, do a disco#items as described in &xep0060; section 5.2. Those items that have a node ID that starts with "&templatePrefix;" are form templates.

]]>

In the above example there is one form available, "stan.isode.net/accidentreport"

To fetch a template, first identify the node that the template is stored in and then request the last published item for that node, as in &xep0060; 6.5.5

Please fill in all fields to complete this accident report. Accident report form. ]]>

The format of the template should be a standard &xep0004; form; this can be extended with &xep0122; and/or &xep0141; as needed by individual form applications. The template will be the pubsub item.

When the form has been completed, the resultant &xep0004; payload shall be published to the completed items node corresponding to the form type using the protocol in &xep0060; 7.1. The node ID for publishing completed forms corresponds to the node the template was stored in, with the &templatePrefix; prefix replaced with the &completedPrefix; prefix.

Accident report form. Kitchen Ankle 1 ]]>

An entity can monitor completed forms by subscribing to the completed form node, as described in &xep0060; 6.1.

]]>

Form templates are made available by publishing them to the template node for that form using the protocol in &xep0060; 7.1.

Please fill in all fields to complete this accident report. Accident report form. ]]>

Template nodes must be configured to support at least one persistent item. Both templates and published nodes need to be configured with appropriate access to publish and subscribe. Deployments may be configured such that entities are allowed to read the templates and submit completed forms, but not to read the completed forms.

All of the form activity happens over standard pubsub, so initial discovery is of the pubsub domain. A pubsub domain supporting these forms will have an additional disco identity (additional to the standard pubsub identity) with a category of 'pubsub' and a type of 'urn:xmpp:fdp:0'.

]]> ]]>

Discovery of the template forms or completed form nodes happens using the protocol described in Use Cases.

This document introduces no security considerations beyond those in &xep0060;.

This document requires no interaction with &IANA;.

Include the "urn:xmpp:fdp:0" namespace in the registry of protocol namespaces. Include "urn:xmpp:fdp:0" as an additional type in the pubsub category of service discovery identities.

As this document only defines semantics for existing protocol, additional schemas are not required.

Thanks to Matthew Wild, Richard Maudsley and Alex Clayton.