xeps/inbox/rest.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>REST with XMPP</title>
  <abstract>This specification defines how the Representational State Transfer (REST)
  architectural style can be applied to an XMPP overlay network. It specifies
  an XMPP protocol extension for accessing resources and transporting resource metadata and XML-REST encoded
  requests and responses between two XMPP entities.</abstract>
  <legal>
    <copyright>This XMPP Extension Protocol is copyright (c) 1999 - 2014 by the XMPP Standards Foundation (XSF).</copyright>
    <permissions>Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the &quot;Specification&quot;), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.</permissions>
    <warranty>## NOTE WELL: This Specification is provided on an &quot;AS IS&quot; BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##</warranty>
    <liability>In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.</liability>
    <conformance>This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at &lt;<link url='http://xmpp.org/extensions/ipr-policy.shtml'>http://xmpp.org/extensions/ipr-policy.shtml</link>&gt; or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).</conformance>
  </legal>
  <number>xxxx</number>
  <status>ProtoXEP</status>
  <type>Standards Track</type>
  <sig>Standards</sig>
  <approver>Council</approver>
  <dependencies>
    <spec>XMPP Core</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>NOT_YET_ASSIGNED</shortname>
  <author>
    <firstname>Alexander</firstname>
    <surname>Stanik</surname>
    <email>alexander.stanik@tu-berlin.de</email>
    <uri>http://www.cit.tu-berlin.de/</uri>
  </author>
  <revision>
    <version>0.0.1</version>
    <date>2015-05-11</date>
    <initials>as</initials>
    <remark><p>First draft.</p></remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>Representational State Transfer (<cite>REST</cite>) is an architectural style that is a coordinated
  set of constraints which also apply to the web. It aims at simplifying component implementations, reducing
  the complexity of distributed software elements, improving the performance, and increasing the
  scalability. In relation to the definition of a RESTful application programming interface (API)
  the uniform interface constraint is of high importance. It simplifies and decouples the architecture
  and makes REST components independent. The constraints for a uniform interface can be reduced to:
  the identification of resources, the self-descriptive representation of resources, and the
  self-descriptive manipulation of resources.</p>
  <p>REST systems typically communicate over the Hypertext Transfer Protocol (HTTP) and are gaining
  large acceptance due to its
  growing support and its simplicity for implementation. RESTful web services
  are in this context a simpler alternative to &w3soap; and WSDL-based Web services which are specified
  for the use with XMPP
  in &xep0072; and also a more powerful alternative to &xmlrpc; which are specified as XMPP extension
  in &xep0009;.</p>
  <p>The &xep0332; allows for designing REST services in the context of XMPP, but requires an implementation
  of both protocols: XMPP and HTTP. Furthermore, HTTP was selected in the past because of its
  degree of popularity, but has some drawbacks like the lack of discoverability of services.
  The REST with XMPP extension is a powerful protocol for cloud services that has
  several advantages in contrast to the traditional HTTP-based REST approach:</p>
  <ol>
    <li>services are discoverable and explorable,</li>
    <li>asynchronous invocation can be performed in parallel,</li>
    <li>generation of clients on the fly based on the capabilities of resources, and</li>
    <li>multiple input and output types definitions are possible.</li>
  </ol>
  <p>The REST with XMPP protocol makes use of the &IQ; stanza in order to enable access, to create, to delete,
  or to modify resources within a XMPP network overlay. This specification defines two XML Schema files:
  one for exploring the capabilities of a resource and one for performing actions on a resource.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
  <p>The author has designed the REST with XMPP protocol with the following requirements in mind:</p>
  <ul>
  	<li><p>REST with XMPP should be easy to implement such as it is with REST over HTTP.</p></li>
  	<li><p>This specification should apply the REST architectural style to XMPP and should eliminate limitations of HTTP.</p></li>
  	<li><p>Resources should be linkable in terms of static connections as well as link targets used for resource access and modifications.</p></li>
  	<li><p>The number of request and <strong>response</strong> parameters, representations and links should be unbounded.</p></li>
  	<li><p>The number of operations should be unlimited as in contrast to HTTP's GET, POST, PUT, DELETE methods.</p></li>
  </ul>
</section1>
<section1 topic='Resource Exploration' anchor='restdis'>
  <p>In order to explore the capabilities of a resource, the &IQ; stanza type "get" have to be used. The returned
  &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be
  complied with the xwadl schema of this specification. The xwadl schema has been designed for providing a machine
  process-able description of a resource. It was inspired by the Web Application Description Language (WADL)
  standard delivered by the World Wide Web Consortium (W3C).</p>
  <p>An &IQ; stanza of type "get" is returning an &IQ; stanza of type "result" that describes all actions that the
  requesting party can perform. The following example shows an exploration of a cloud provider's REST based
  interface for handling compute services.</p>
      <!-- computeExplorationRequestIQ.xml -->
      <example caption='Exploration of an OpenStack interface for handling compute services'><![CDATA[
<iq type='get'
    from='requester@company-b.com/rest-client'
    to='company-a.com/openstack'
    id='rest1'>
  <resource_type xmlns="urn:xmpp:rest-xwadl" path="/compute" />
</iq>
      ]]></example>
  <p>In order to explore a resource, only the path to a resource is required. The counter party has to
  answer of such a request with a response that exposes all possible actions which can be performed on the
  resource located at the specified path. The following example illustrates a response that exposes all
  actions for this resource.</p>
      <!-- computeExplorationResponseIQ.xml -->
      <example caption='Result of an exploration for handling compute services'><![CDATA[
<iq type="result"
    from="company-a.com/openstack"
    to="requester@company-b.com/rest-client"
    id="rest1">
  <resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
    <doc title="Compute resource management">
        Use one of the following actions to manage your compute instances!
    </doc>
    <method name="create">
      <request>
        <param name="image" required="true" repeating="false">
          <option link="remote"/>
        </param>
        <param name="flavors" repeating="false" default="m1.small">
          <option type="xs:string">m1.small</option>
          <option type="xs:string">m2.medium</option>
          <option type="xs:string">m3.large</option>
        </param>
        <param name="number" repeating="false" default="1">
          <doc title="number of requested virtual machnies"/>
          <option type="xs:integer"/>
        </param>
      </request>
      <response>
        <param name="newVM">
          <option link="list"/>
        </param>
      </response>
    </method>
    <method name="sla">
      <response>
        <param name="computeSla">
          <option mediaType="text/plain"/>
          <option mediaType="application/json"/>
        </param>
      </response>
    </method>
  </resource_type>
</iq>
      ]]></example>
  <p>This response exposes two methods that can be performed on the
  resource located at "/compute". The first method "create" can be used to create one or
  more virtual machines (VM). This method has three input parameters in its request and one output
  parameter in its response. If a client would like to perform this method, at least only a link to
  the location of an image is required. The other two parameters are optional. The server will respond to this
  method with a list of links to the instantiated VMs. A detailed example of how to access this method is
  illustrated in the <link url='#restaccess'>Resource Access</link> section.</p>
  <p>The following subsections describe each component of a xwadl document in detail.</p>
  <section2 topic='Resource Type' anchor='restdis-resourcetype'>
    <p>The "resource_type" element forms the root of a xwadl document and MAY comprises the following
    sub-elements: "doc", "grammars", and "method"</p>
  </section2>
  <section2 topic='Documentation' anchor='restdis-documentation'>
    <p>Each xwadl-defined element down to the "param" can have one or more child "doc" elements that
    can be used to document that element. The doc element has "title" attributes which is a short plain
    text description of the element being documented. The "doc" element can have mixed content
    and may contain text and zero or more child elements.</p>
  </section2>
  <section2 topic='Grammars' anchor='restdis-grammars'>
    <p>The "grammars" element acts as a container for definitions of the format of data exchanged
    during execution of the protocol described by the xwadl document and SHOULD be according to the
    XML Schema definition.</p>
      <!-- grammarsExampleResponseIQ.xml -->
      <example caption='Example xwadl document with a grammars element'><![CDATA[
<iq type="result"
    from="responder@company-a.com"
    to="requester@company-b.com/rest-client"
    id="rest1">
  <resource_type xmlns="urn:xmpp:rest-xwadl" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/address-book">
    <grammars>
      <doc title="Person List"/>
      <xs:element name="PersonList" type="MyStructType"/>
      <xs:complexType name="MyStructType">
        <xs:sequence>
          <xs:element name="Person" type="MyPersonType" maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:complexType>
      <xs:complexType name="MyPersonType">
        <xs:sequence>
          <xs:element name="name" type="xs:string"/>
          <xs:element name="age" type="xs:integer"/>
        </xs:sequence>
      </xs:complexType>
    </grammars>
    <method name="POST">
      <request>
        <param name="persons" required="true" repeating="false">
          <option type="MyStructType"/>
        </param>
      </request>
      <response/>
    </method>
  </resource_type>
</iq>
      ]]></example>
  </section2>
  <section2 topic='Method' anchor='restdis-method'>
    <p>A method element describes the specific actions that can be performed on a resource targeted
    by the "path" attribute of the "resource_type" element.
    A method element is a child of a "resource_type" element and has a "name" attribute
    that identifies this method.</p>
    <p>Additionally, each "method" MUST have one "request" and one "response" element
    which can be empty or be used to expose the optional parameters that this method can execute.</p>
  </section2>
  <section2 topic='Request and Response' anchor='restdis-reqeesp'>
    <p>The "request" and the "response" element are according to the xwadl schema of type "call". They are
    identical by definition and describe the input and output data for accessing a resource.</p>
    <ul>
      <li>A <strong>request</strong> describes the <strong>input</strong> to the method as a collection of parameters.</li>
      <li>A <strong>response</strong> describes the <strong>output</strong> to the method as a collection of parameters.</li>
    </ul>
    <p>Both elements describe the information to be included when applying a method to a resource.
    Both elements have no attributes and may contain one or more "param" elements as child elements.</p>
  </section2>
  <section2 topic='Parameter' anchor='restdis-parameter'>
    <p>A "param" element describes a parameterized component of its parent element (either a request or a
    response). It can be identified by its "name" attribute and MUST have a minimum of one "option" element
    that defines one of a set of possible
    values for the parameter. In order to parameterize a component, the "param" element SHOULD specify
    a combination of the following attributes:</p>
    <ul>
      <li>The <strong>name</strong> attribute specifies the name of the parameter and is a required attribute.</li>
      <li>The <strong>default</strong> attribute specifies an OPTIONAL default value that is applied if this
      parameter is not used while accessing a resource. If this attribute is specified, the overall parameter
      element is optional when accessing a resource.</li>
      <li>The <strong>required</strong> attribute is an OPTIONAL element and can be either false or true (default is false).
      It indicates whether the parameter is required to be present or not.</li>
      <li>The <strong>repeating</strong> attribute is an OPTIONAL element and can be either false or true (default is false).
      It indicates whether the parameter is single valued or may have multiple values.</li>
    </ul>
    <p>Some combinations of attributes do not make sense, e.g. the specification of "default=?" and "repeating=true",
    and SHOULD be considered application specific.</p>
  </section2>
  <section2 topic='Option' anchor='restdis-option'>
    <p>An "option" element defines one of a set of possible types, representations, link type, or also values
    for the parameter. An "option" element MUST have one of the following attributes:</p>
    <dl>
      <di>
        <dt>type</dt>
        <dd>
          <p>The "type" attribute indicates one possible type of the parameter as an XML qualified name,
          defaults to xs:string. It SHOULD specify the type of a single optional value. Multiple options
          with the same type but different values SHOULD specify a set of possible values which are
          acceptable as input for the parent parameter.</p>
        </dd>
      </di>
      <di>
        <dt>mediaType</dt>
        <dd>
          <p>The "mediaType" attribute indicates that the parent parameter acts as a media type selector
          for requests or responses. The value of the attribute is the media type that is expected. If
          a representation of an OPTIONAL media type is exposed, this representation can act as a
          template for manipulating a resource.</p>
        </dd>
      </di>
      <di>
        <dt>link</dt>
        <dd>
          <p>The "link" attribute is used to identify links to resources. It can have the value local, remote,
          or list. A local link links to another resource located at the same server entity. A remote link links to
          a resource located at another server entity anywhere in the XMPP network overlay. A link with a
          list value indicates a list of remote links that can be used for discovery or linking to a set
          of resources.</p>
        </dd>
      </di>
    </dl>
  </section2>
</section1>
<section1 topic='Resource Access' anchor='restaccess'>
  <p>In order to access a resource, the &IQ; stanza type "set" has to be used. The returned
  &IQ; stanza is either of type "error" or "result". If it is of type "result", the returned content has to be
  complied with the xml-rest schema of this specification. The xml-rest schema has been designed
  for providing a xml-rest encoded payload for accessing a resource.
  An &IQ; stanza MUST NOT contain more than one method element with one request and one response.
  The following example illustrates how the create method of the previous example is requested.
  Here, the client requests three VMs which are based on an image that is available as resource
  on the client's side.</p>
      <!-- computeCreateRequestIQ.xml -->
      <example caption='Access of an OpenStack interface to create a virtual machnine'><![CDATA[
<iq type="set"
    from="requester@company-b.com/rest-client"
    to="company-a.com/openstack"
    id="rest2">
  <resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
    <method name="create">
      <request>
        <param name="image">
          <link>
            <to>requester@company-b.com/rest-client</to>
            <path>/images/myLinuxImage</path>
          </link>
        </param>
        <param name="number">
          <value type="xs:integer">3</value>
        </param>
      </request>
      <response>
        <param name="newVM">
          <resourceList/>
        </param>
      </response>
    </method>
  </resource>
</iq>
      ]]></example>
  <p>In order to make sure that both parties have a common understanding, the requester specifies also
  the expected responds type which has been exposed during the exploration step. The counter party has to
  answer such a request with the same request element and an extended complitation of the response
  element as illustrated in the example below.
  </p>
      <!-- computeCreateRequestIQ.xml -->
      <example caption='Result of an access to create a virtual machnine'><![CDATA[
<iq type="result"
    from="company-a.com/openstack"
    to="requester@company-b.com/rest-client"
    id="rest2">
  <resource xmlns="urn:xmpp:xml-rest" xmlns:xs="http://www.w3.org/2001/XMLSchema" path="/compute">
    <method name="create">
      <request>
        <param name="image">
          <link>
            <to>requester@company-b.com/rest-client</to>
            <path>/images/myLinuxImage</path>
          </link>
        </param>
        <param name="number">
          <value type="xs:integer">3</value>
        </param>
      </request>
      <response>
        <param name="newVM">
          <resourceList>
            <link>
              <to>dc1.company-a.com/openstack</to>
              <path>requester/vms/vm1</path>
            </link>
            <link>
              <to>dc2.company-a.com/openstack</to>
              <path>requester/vms/vm02</path>
            </link>
            <link>
              <to>dc3.company-a.com/openstack</to>
              <path>requester/vms/vm003</path>
            </link>
          </resourceList>
        </param>
      </response>
    </method>
  </resource>
</iq>
      ]]></example>
  <p>The following subsections describe each component of a xml-rest document in detail.</p>
  <section2 topic='Resource' anchor='restaccess-resource'>
    <p>The "resource" element forms the root of an xml-rest document and MUST comprise only a
    single "method" sub-element. In contrast to the xwadl description, no further documentation or grammers
    are possible in order to keep the number of bytes as low as possible.
    In order to specify the resource to access, the "path" attribute is required.</p>
  </section2>
  <section2 topic='Method' anchor='restaccess-method'>
    <p>The "method" element MUST have one request element and one response element. Additionally, the
    "name" attribute is required in order to identify the action that has to be performed on the resource.</p>
  </section2>
  <section2 topic='Request and Response' anchor='restaccess-reqeesp'>
    <p>The "request" and the "response" element are according to the xml-rest schema of type "call". They are
    identical by definition and including the information for applying the method of a resource.
    Both elements have no attributes and may contain one or more "param" elements as child elements.</p>
    <ul>
      <li>A <strong>request</strong> includes the <strong>input data</strong> to the method as a collection of parameters.</li>
      <li>A <strong>response</strong> includes the <strong>output data</strong> to the method as a collection of parameters.</li>
    </ul>
  </section2>
  <section2 topic='Parameter' anchor='restaccess-parameter'>
    <p>Each "param" element has a "name" attribute to identify the parameter and a single sub-element
    that includes the data. Possible sub-elements are value, representation, link, or resourceList.</p>
  </section2>
  <section2 topic='Value' anchor='restaccess-value'>
    <p>The "value" element has a "type" attribute that specifies the type of the value.</p>
  </section2>
  <section2 topic='Representation' anchor='restaccess-representation'>
    <p>The "representation" element has a "mediaType" attribute that specifies the media type of the representation.</p>
  </section2>
  <section2 topic='Link and Resource List' anchor='restaccess-link'>
    <p>A "link" element or a "resourceList" element have no attributes. While a link targets to a single local
    or remote location, a resource list is a set of links which are targeting to any resource in an XMPP
    overlay network. A link can be expressed in two forms: as XMPP resource link with a "to"
    (e.g. &lt;to&gt;requester@company-b.com/rest-client&lt;/to&gt;) and a "path" (e.g.
    &lt;path&gt;/images/myLinuxImage&lt;/path&gt;) element
    or as URI (&lt;uri&gt;xmpp://requester@company-b.com/rest-client?/images/myLinuxImage&lt;/uri&gt;).</p>
  </section2>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
  <!-- section2 topic='Retrieving a specific representation' anchor='usecases-intercloud'>
    <p>Example to access the sla method.</p>
  </section2 -->
  <section2 topic='Multi-Dimensional Resource Placement' anchor='usecases-multi-dim'>
    <p>The REST with XMPP protocol enables a multi-dimensional resource placement. The following examples show
    how different resources can be placed within a single server entity:</p>
      <example caption='A request to a server'><![CDATA[
<iq type='set'
    from='requester@company-b.com/rest-client'
    to='company-a.com'
    id='rest1'>
  <resource xmlns="urn:xmpp:xml-rest" path="/">
    ...
  </resource>
</iq>
  ]]></example>
      <example caption='A request to a server with a JID contained a resource part'><![CDATA[
<iq type='set'
    from='requester@company-b.com/rest-client'
    to='company-a.com/resource'
    id='rest1'>
  <resource xmlns="urn:xmpp:xml-rest" path="/">
    ...
  </resource>
</iq>
  ]]></example>
      <example caption='A request to a server with a JID contained a local part'><![CDATA[
<iq type='set'
    from='requester@company-b.com/rest-client'
    to='responder@company-a.com'
    id='rest1'>
  <resource xmlns="urn:xmpp:xml-rest" path="/">
    ...
  </resource>
</iq>
  ]]></example>
      <example caption='A request to a server with a JID contained a local and a resource part'><![CDATA[
<iq type='set'
    from='requester@company-b.com/rest-client'
    to='responder@company-a.com/resource'
    id='rest1'>
  <resource xmlns="urn:xmpp:xml-rest" path="/">
    ...
  </resource>
</iq>
  ]]></example>
      <example caption='A request to a server with a JID contained a local and a resource part, but accesses another resource'><![CDATA[
<iq type='set'
    from='requester@company-b.com/rest-client'
    to='responder@company-a.com/resource'
    id='rest1'>
  <resource xmlns="urn:xmpp:xml-rest" path="/resource/">
    ...
  </resource>
</iq>
  ]]></example>
  <p>All examples above are accessing different resources. A variation of the path attribute of the resource
  element would also combine the presented JIDs and referring to different resources.
  Further examples are possible to show how different resources can be located at a single server entity.</p>
  </section2>
</section1>
<section1 topic='Service Discovery' anchor='disco'>
  <p>If an entity supports the REST with XMPP protocol, it SHOULD advertise that fact in response to &xep0030; information ("diso#info") requests by returning an identity of "automation/rest" and a feature of "jabber:iq:rest":</p>
  <example caption='A disco#info query'><![CDATA[
<iq type='get'
    from='requester@company-b.com/rest-client'
    to='responder@company-a.com/rest-server'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
  ]]></example>
  <example caption='A disco#info response'><![CDATA[
<iq type='result'
    to='requester@company-b.com/rest-client'
    from='responder@company-a.com/rest-server'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <identity category='automation' type='rest'/>
    <feature var='jabber:iq:rest'/>
  </query>
</iq>
  ]]></example>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>Determining when and how a resource can be accessed or modified based on permissions or
  rights are considered outside the scope of this document. Although such mechanisms SHOULD be
  considered specifically to the application and/or implementation of this document,
  future specifications may address these concerns.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>REQUIRED.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
    <p>The &REGISTRAR; includes 'urn:xmpp:rest:xwadl' and 'urn:xmpp:rest:xml' in its registry of protocol namespaces.</p>
  </section2>
  <section2 topic='Service Discovery Identity' anchor='registrar-disco'>
    <p>The XMPP Registrar includes a Service Discovery type of "rest" within the "automation" category in its registry of service discovery identities.</p>
  </section2>
</section1>
<section1 topic='XML Schema' anchor='schema'>
    <section2 topic='XWADL Schema' anchor='schema-xwadl'>
    <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	targetNamespace="urn:xmpp:rest-xwadl" xmlns="urn:xmpp:rest-xwadl"
	elementFormDefault="qualified">

	<xs:annotation>
		<xs:documentation>
			The protocol documented by this schema is defined in
			XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
		</xs:documentation>
	</xs:annotation>

	<xs:element name="resource_type">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="doc" minOccurs="0" maxOccurs="unbounded" />
				<xs:element ref="grammars" minOccurs="0" />
				<xs:element ref="method" minOccurs="0" maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="path" type="xs:string" use="required" />
		</xs:complexType>
	</xs:element>

	<xs:element name="doc">
		<xs:complexType mixed="true">
			<xs:sequence>
				<xs:any namespace="##other" processContents="lax" minOccurs="0"
					maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="title" type="xs:string" />
		</xs:complexType>
	</xs:element>

	<xs:element name="grammars">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="doc" minOccurs="0" maxOccurs="unbounded" />
				<xs:any namespace="##other" processContents="lax" minOccurs="0"
					maxOccurs="unbounded" />
			</xs:sequence>
		</xs:complexType>
	</xs:element>

	<xs:element name="method">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="doc" minOccurs="0" maxOccurs="unbounded" />
				<xs:element ref="request" minOccurs="0" maxOccurs="1" />
				<xs:element ref="response" minOccurs="0" maxOccurs="1" />
			</xs:sequence>
			<xs:attribute name="name" type="xs:string" />
		</xs:complexType>
	</xs:element>

	<xs:element name="request" type="call" />

	<xs:element name="response" type="call" />

	<xs:complexType name="call">
		<xs:sequence>
			<xs:element ref="doc" minOccurs="0" maxOccurs="unbounded" />
			<xs:element ref="param" minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>

	<xs:element name="param">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="doc" minOccurs="0" maxOccurs="unbounded" />
				<xs:element ref="option" minOccurs="1" maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="name" type="xs:string" use="required" />
			<xs:attribute name="default" type="xs:string" />
			<xs:attribute name="required" type="xs:boolean" default="false" />
			<xs:attribute name="repeating" type="xs:boolean" default="false" />
		</xs:complexType>
	</xs:element>

	<xs:element name="option">
		<xs:complexType mixed="true">
			<xs:sequence>
				<xs:any namespace="##other" processContents="lax" minOccurs="0"
					maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="type" type="xs:QName" default="xs:string" />
			<xs:attribute name="mediaType" type="xs:string" />
			<xs:attribute name="link" type="linkTarget" />
		</xs:complexType>
	</xs:element>

	<xs:simpleType name="linkTarget">
		<xs:restriction base="xs:string">
			<xs:enumeration value="local" />
			<xs:enumeration value="remote" />
			<xs:enumeration value="list" />
		</xs:restriction>
	</xs:simpleType>

</xs:schema>
	]]></code>
	</section2>
	<section2 topic='XML-REST Schema' anchor='schema-rest'>
    <code><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
	targetNamespace="urn:xmpp:xml-rest" xmlns="urn:xmpp:xml-rest"
	elementFormDefault="qualified">

	<xs:annotation>
		<xs:documentation>
			The protocol documented by this schema is defined in
			XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
		</xs:documentation>
	</xs:annotation>

	<xs:element name="resource">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="method" minOccurs="1" maxOccurs="1" />
			</xs:sequence>
			<xs:attribute name="path" type="xs:string" use="required" />
		</xs:complexType>
	</xs:element>

	<xs:element name="method">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="request" minOccurs="0" maxOccurs="1" />
				<xs:element ref="response" minOccurs="0" maxOccurs="1" />
			</xs:sequence>
			<xs:attribute name="name" type="xs:string" />
		</xs:complexType>
	</xs:element>

	<xs:element name="request" type="call" />

	<xs:element name="response" type="call" />

	<xs:complexType name="call">
		<xs:sequence>
			<xs:element ref="param" minOccurs="0" maxOccurs="unbounded" />
		</xs:sequence>
	</xs:complexType>

	<xs:element name="param">
		<xs:complexType>
			<xs:choice minOccurs="0" maxOccurs="1">
				<xs:element ref="value" />
				<xs:element ref="representation" />
				<xs:element ref="resourceList" />
				<xs:element ref="link" />
			</xs:choice>
			<xs:attribute name="name" type="xs:string" use="required" />
		</xs:complexType>
	</xs:element>

	<xs:element name="value">
		<xs:complexType mixed="true">
			<xs:sequence>
				<xs:any namespace="##other" processContents="lax" minOccurs="0"
					maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="type" type="xs:QName" use="required" />
		</xs:complexType>
	</xs:element>

	<xs:element name="representation">
		<xs:complexType mixed="true">
			<xs:sequence>
				<xs:any namespace="##other" processContents="lax" minOccurs="0"
					maxOccurs="unbounded" />
			</xs:sequence>
			<xs:attribute name="mediaType" type="xs:string" use="required" />
		</xs:complexType>
	</xs:element>

	<xs:element name="resourceList">
		<xs:complexType>
			<xs:sequence>
				<xs:element ref="link" minOccurs="0" maxOccurs="unbounded" />
			</xs:sequence>
		</xs:complexType>
	</xs:element>

	<xs:element name="link">
		<xs:complexType>
			<xs:choice minOccurs="1" maxOccurs="1">
				<xs:sequence>
					<xs:element name="to" type="xs:string" minOccurs="0"
						maxOccurs="1" />
					<xs:element name="path" type="xs:string" minOccurs="1"
						maxOccurs="1" />
				</xs:sequence>
				<xs:element name="uri" type="xs:string" />
			</xs:choice>
		</xs:complexType>
	</xs:element>

</xs:schema>
	]]></code>
	</section2>
</section1>
</xep>