4.10 Inlined Schemas

SData provides an option to include schema information directly into feeds. This option has been introduced to improve performance on mobile devices and avoid additional roundtrips to read a schema.

A consumer MAY request that the provider include the schema by adding an includeSchema parameter to its feed or resource URL. For example:

GET /sdata/myApp/myContract/-/salesOrders?includeSchema=true

The provider will respond with an SData sales order feed. The included schema is placed inside an <sdata:schema> element, as follows:

<feed xmlns:sdata="http://schemas.sage.com/sdata/2008/1" 
      xmlns:http="http://schemas.sage.com/sdata/http/2008/1" 
      xmlns:opensearch="http://a9.com/-/spec/opensearch/1.1/"
      xmlns:sle="http://www.microsoft.com/schemas/rss/core/2005" 
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xmlns="http://www.w3.org/2005/Atom">

  <!-- Atom feed elements -->
  <title>Sage App | Sales Orders</title>
  <id>http://www.example.com/sdata/myApp/myContract/-/salesOrders</id>
  <updated>2008-03-31T13:46:45Z</updated>

  <!-- Feed level links  - skipped for clarity --> 
  <!-- Categories - skipped for clarity -->
  <!-- Paging information - skipped for clarity-->
  <!-- Simple List Extensions - skipped for clarity-->

  <!-- Embedded schema -->
  <sdata:schema> 
    <xs:schema xmlns:tns="http://schemas.sage.com/myContract" 
           targetNamespace="http://schemas.sage.com/myContract" 
           xmlns:sme="http://schemas.sage.com/sdata/sme/2007" 
           xmlns:xs="http://www.w3.org/2001/XMLSchema">

      <xs:element name="salesOrder" type="tns:salesOrder--type" 
        sme:role="resourceKind" sme:pluralName="salesOrders" sme:label="Sales Order"
        sme:canGet="true" sme:canPost="true" sme:canPut="true" sme:canDelete="true"
        sme:supportsETag="true" sme:batchingMode="syncOrAsync" />
      <xs:complexType name="salesOrder--type">
        <xs:all>
          <xs:element name="orderNumber" type="xs:string" minOccurs="0"
                      sme:label="#" sme:canSort="true" sme:canFilter="true" sme:precedence="1" 
                      sme:isUnique="true" sme:isReadOnly="true"/>
          <xs:element name="orderDate" type="xs:date" minOccurs="0"
                      sme:label="Date" sme:canSort="true" sme:canFilter="true" sme:precedence="2" />
          <xs:element name="shipDate" type="xs:date" minOccurs="0" nillable="true"
                      sme:label="Shipping Date" sme:canSort="true" sme:canFilter="true" sme:precedence="3" />
          <xs:element name="subTotal" type="xs:decimal" minOccurs="0"
                      sme:label="Sub-total" sme:canSort="true" sme:canFilter="true" sme:precedence="2" 
                      sme:isReadOnly="true" />
          <xs:element name="billAddress" type="tns:address--type" minOccurs="0"
                      sme:relationship="child" sme:isCollection="false" sme:label="Billing Address" 
                      sme:canGet="true" sme:canPut="true" />
          <xs:element name="shipAddress" type="tns:address--type" minOccurs="0"
                      sme:relationship="child" sme:isCollection="false" sme:label="Shipping Address" 
                      sme:canGet="true" sme:canPut="true" />
        </xs:all>
      </xs:complexType>

      <xs:complexType name="address--type">
        <xs:all>
          <xs:element name="street" type="xs:string" 
                      sme:label="Street" /> 
          <xs:element name="city" type="xs:string" 
                      sme:label="City" />
          <xs:element name="postalCode" type="xs:string" 
                      sme:label="Postal Code" />
          <xs:element name="countryCode" type="xs:string" 
                      sme:label="County Code" />
        </xs:all>
      </xs:complexType>

    </xs:schema>
  </sdata:schema>

  <!-- Atom entries - skipped for clarity -->

</feed>

If the request returns an individual entry rather than a feed, the <sdata:schema> element is included in the entry as a sibling to the <sdata:payload> element.

The definition of the salesOrder resource kind was trimmed in this schema fragment. The contact property has been removed because including it would force the inclusion of the contact--type type definition. This feature should be used with simplified "mobile contracts" in which the resources don't have too many dependencies. Otherwise it might be difficult to extract valid schema fragments for a resource kind.

SData providers MAY choose to NOT honour the includeSchema parameter. If they do not honour it and do not include the schema, they MUST at least return a <link> element with the schema's URL. The consumer should recognize this and should read the schema with a separate GET request. This parameter is only a hint.