Opaque Bodies, Transparent Envelopes
Vol. 1 Issue 5, p61
Listing 1

<?xml version="1.0"?>

<Message xmlns="x-schema:MessageSchema.xml">
   <Header>
   <!-- When this document was built, routing
   information was copied from the body to the
   header, to avoid breaking opaqueness during
   transmission -->
      <TargetAddress>
         joe@anywhere.com
      </TargetAddress>
   </Header>

   <!-- This is an opaque body. It could
   include text, markup elements, or both.
   Schema for item placed in the body
   should be defined separately, and available
   to sender and recipient in a
   common repository. Because it is not CDATA,
   this body is not completely opaque: It will
   be parsed and must be well formed and valid if
   the parser requires that.-->
 
   <Body>
      <Order xmlns="x-schema:OrderSchema.xml">
         <Target>
            joe@anywhere.com
         </Target>
         <Item>
            Garden chair
         </Item>
      </Order>
   </Body>
 
   <Body>
   <!-- The second example of a body element of
   this messge is totally opaque. It demonstrates
   the embedding of an XML message in another
   where the body's schema is not currently
   available. This data will be left unparsed
   (saving parsing time) until the recipient
   "unpacks" it. It does not even have to be
   well-formed or valid.-->
       <![CDATA[
        <?xml version="1.0"?>
        <Purchase xmlns="x-schema: http://www.unavailable.com/purchaseSchema.xml">
         <Price currency="USD">54.00</Price>
         <SKU>209238</SKU>
        </Purchase>
       ]]>
   </Body>
</Message>
 
 

Listing 2
<!--
To preserve opaqueness of body, this Schema is
defined separately from any schema that may be
placed in the body, such as the OrderSchema.

This example uses Microsoft's XML-Data pre-standard
variant of Schemas, for which validators are
currently available. Standard Schemas should be
quite similar when the recommendation is approved
by the W3. Some examples in the text are based on
that proposal, since Microsoft XML-Data does not
support derivation.
-->
<Schema xmlns="urn:schemas-microsoft-com:xml-data"
   xmlns:dt="urn:schemas-microsoft-com:datatypes">
 
  <ElementType name="TargetAddress" content="textOnly"/>
 
  <ElementType name="Header" content="eltOnly">
    <element type="TargetAddress"/>
  </ElementType >
 
  <!-- Note that the content of the body is left
  open, to allow for opaqueness. -->
  <ElementType name="Body" content="mixed" model="open"/>
 

  <ElementType name="Message" content="eltOnly">
    <element  maxOccurs="1"  minOccurs="1" type="Header"/>
  <!--This schema allows for multi-part bodies
  with maxOccurs="*" -->
    <element  maxOccurs="*"  minOccurs="1" type="Body"/>
  </ElementType>
</Schema>
 
 

Listing 3
<!--
To preserve transparency of messaging format
this Schema is defined separately from any schema
that may be placed in the body, such as
the MessageSchema.
-->
<Schema xmlns="urn:schemas-microsoft-com:xml-data"
        xmlns:dt="urn:schemas-microsoft-com:datatypes">
  <ElementType name="Target" dt:type="string" content=
"textOnly"/>
  <ElementType name="Item" dt:type="string" content=
"textOnly"/>
 
  <ElementType name="Order" content="eltOnly" model="open" order ="seq">
        <element type="Target"/>
        <element type="Item"/>
  </ElementType>
</Schema>
 
 

Listing 4
<!&#151;This is a counter-example! Don't try this yourself! The CDATA section, as it would be incorrectly understood by a parser, is highlighted. -->
<outerMessage>
 <! [CDATA[
  <intermediateMessage>
   <! [CDATA[
    <innermostBody/>
   ]]>
</ intermediateMessage >
]]>
</outerMessage>