We can think of a message as being structured in the following way:

• A message containing information about the information aggregator and aggregation services, and then containing on ore more data items included in the message.
• The message may, in turn, contain additional syndicated data messages perhaps originating from different syndication sources.
• The different items in the message might be related in some way (different language versions, images associafed with web pages, etc.). So we need a way of grouping stuff together that's related.

A basic structural model that reproduces these issues is as follows: The tags marked in red correspond to the actual element names we will incorporate into the language:

 <syndicationMessage>
   <metadata> info about the aggregator </metadata>
   <item>
      <metadata> metadata about the item </metadata>
      <data> the data itself </data>
   </item>
   <item>
      <metadata> metadata about another item </metadata>
      <data> the data itself </data>
   </item>
   ..... 
   <collection>  <!-- a set of somehow related data items -->
      <metadata> metadata about the collection </metadata>
      <item>
         <metadata> metadata about another item </metadata>
         <data> the data itself </data>
      </item>
      <item>
         <metadata> metadata about another item </metadata>
         <data> the data itself </data>
      </item>
      ....
   </collection>
   <syndicationMessage> .. another syndication message 
   </syndicationMessage>
</syndicationMessage>

By implication, the metadata describing the aggregator would apply to the content of all items or collections. However, a message can contain subsequent syndication messages to redefine the aggregator information for their content. This would, in principle, let one aggregation service forward aggregated data from a third party, including with it the information needed to recontact the 'original' aggregation service.

Identifying Items

Each data item needs to be identifiable so that it can be re-gathered or referenced. Thus it makes sense that each item element have attributes to do this. Three attributes would seem appropriate:

• a URL that will re-retrieve a 'most current' version of that item from the same aggregation service. We can name this the src attribute.
• a URL that will re-retrieve exactly the same version of that item from the same aggregation service. We can name this the usrc attribute.
• a unique identifier for the item (which varies with each version). this need only be unique for each aggregation service -- a complete unique identifier would be the combination of the unique identifier and for the item plus the identifier for the aggragator. We can name this the uuid attribute.

All of these properties would in principle be optional, but in practice they are necessary for various common syndication mechanisms (such as refreshing for a new version of the content, or for internally referencing items within a message.

Elements Requiring Identification

These properties could also be set for any element that 'groups' data and metadata together, namely (using the notation in the previous example) item, collection or syndicationMessage elements.

Date and Timestamps Attributes

The syndicationMessage element will need a time stamp to state when the message was created or assembled. At the same time, each item element should be able to define when the item was created and last modified. This calls for two attributes:

• created, to define when an item or syndicationMmessage was created, and
• lastModified, to define when an item was last modified.

Note that the creation date for a mesage is not inherited by content inside the message -- saying that a message was assembled at some time in no way implies that the content was also created at that time.

Human Language Identification

It will often be useful to idenfity the human language of a collection or item element and its content. This is accomplished using an xml:lang attribute.

The following are some simple examples showing the broad outline of a message's structure. The urls, universal identifiers and date/time values are simple illustrations, and do not represent real values or syntax specifications.

Example 1

Here is the outline of a complex message contining items and a collection containing items Note the use of the xmlns attribute in the root element to identify the syndicationMessage namespace.

<syndicationMessage src="http://www.foo.org/dataport?id=2323223"
                    usrc="http://www.foo.org/dataport?id=2323223&v=0.23"
		    uuid="z2323232.v023x"
		    created="20000324T12:32:15Z" 
		    xmlns="http://www.xxx.org/namespace" >

  ... metadata ...
  <item src="http://www.foo.org/dataport?item=23141
        usrc="http://www.foo.org/dataport?item=23141&v=0121
        uuid="itemz2323232.v0121"
        created="20000322T11:32:15Z" 
        lastModified="20000324T12:20:15Z" 
        xml:lang="en">
    ..... metadata ....
    </item>
  .... more items ....
  <collection src="http://www.foo.org/dataport?coll=23x23
              usrc="http://www.foo.org/dataport?coll=23x23&v=z2313
              uuid="col23x23.z2313"
              created="20000321T11:32:15Z" 
              lastModified="20000324T12:20:15Z" 
              xml:lang="en">
     <item> ... insie the collection</item>
     <item> ... insie the collection</item>
  </collection>
</syndicationMessage>

Example 2: A Minimal Collection

Here is a minimal message providing essentially no inforamtion about the message parts. This is perfectly acceptble, although the consumer may have trouble using the data effectively.

<syndicationMessage created="20000324T12:32:15Z" 
                    xmlns="http://www.xxx.org/namespace" >
   ... metadata...
   <item >
      ... metadata...
      <data> ... </data>
   </item>
   <item >
      ... metadata...
      <data> ... </data>
   </item>
   <item >
      ... metadata...
      <data> ... </data>
   </item>
</syndicationMessage>