Syndication Format Requirements

In the long run, syndication messages must be able to distribute 
many different types of 'data', along with metadata related to: 

  * simple syndication rules and/or processes, 
  * the author/distributor of the syndication message (or
    parts thereof)
  * the data and/or metadata itself.

Just about any type of data can be syndicated, but from my
observations these types fall into two main categories:

  * a summary about a resource (human readable parts plus 
    machine-readable metadata) that describes a resource and 
    also references (via a URL) the 'full' resource
  * the full content of a resource (in some agreed-upon 
    format)

However, the full resource could be many different things --
an HTML page (or pages), iCalendar or vCard data, or many
other different things. 

Moreover, a syndicated data message could contain multiple 
resources, which may or may not be related.  For example, 
a message might contain a collection of unrelated resources, 
it might contain a set of different language-versions of the 
same resource.  Other relationships would also be possible, 
and the mechanism for expressing this structure should allow 
for some degree of extendibility in this regard.

HOwever, if the structure is rich, then maybe the message
'payload' should take on a format appropriate to this, 
independnet of the 'syndication' notation of the message.

If we call each of these a 'resource', then each resource needs
metatdata associated with it. This metadata provides information 
about the resource needed, by the recipient of the payload, to 
manage the syndication process.

Resource metadata would be 'inherited' by the any resources within
a given resource, while any metadata specified for an inner
resource would override any inherited metadata value.

Syndication Resource Metadata

Metadata relevant to any resource can consists of (the [M] means
taht the data should be in a well-known machine-readable format):

<accessInfo>
This information describes how the resource can be retrieved 
or otherwise accessed/queried. Desired information would 
include:
  - [M] URL of the resource -- accessing this URL will re-retrieve 
    it (or possibly an updated version of it) 
  - [M] Unique ID for the resource (MUST be different for each
    variant of the resource, if it changes over time). Useful only
    if a resource can be retrieved using the UID value.
  - Resource Interface -- a generic interface (URL-based) for
    accessing the server that produces this resource.  This 
    requires specifying:
     - [M] base URL for the interface
     - [M] type of the interface (XML-RPC | SOAP)
     - [M] URL for retrieving a description for the interface
</accessInfo>

<resourceMetaData>
This block contains metadata describing the resource and the
organization/individual that authored the resource. 
  - [M] human contact for resource (if any; email address or other)
  - [M] date resource was created
  - [M] date this message was assembled for delivery
  - [M] date resource was last modified
  - [M] main data type for 'content' 
  - [M] authority data: who is the creator of this syndication resource.
      - [M] URL of organization
      - name of organization
      - [M?] authority digital signature 
      - copyright statements
  - [M] content rating information (e.g. PICS or P3P) 
</resourceMetaData>

<syndicationRules>
This block contains metadata describing the 'syndication rules' 
for the resource. This would include the time interval during which
the resource should be used (it should not be used outside this
range), the interval between regular updates to the resource (should
it be updated on a regular basis),  rules for how the resource
can be passed on/redistributed by the recipient, and finally
access control rules (how can the data be used).?????

  - [M] start time/date for display of data (start showing data 
    after this date)
  - [M] stop time/date for display of data (stop displaying 
    after this date)
  - [M] update interval (mean time between updates to the resource)
  - [M] no more updates - (resource is no longer being updated)
  - [M] redistribution / usage rules (how can this data be reused)
  - [M] access control  (how can this data be used)
</syndicationRules>

<description>
This block contains metadata describing semantic properties of
the resource (e.g., a description/summary of it, the language of
the resource, etc.)
  - [M] human-readable language of the resource
  - [M] keywords appropriate to this resource
  - [M] categories this topic belongs in  (in some hierarchical index)
  - [M] pointer to a catalog describing the keyword category lists used
    for the preceding.
  - free text description of the resource
</description>

<content>
  ... the data being communicated 
</content>


--------------

THe following is an example of this format --

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/92/22-rdf-syntax-ns#"
         xmlns="uri_to_specification" >

<accessInfo>  <!-- information about where this message comes from -->
  <link > _uri-to-resource_ </link>
  <uuid uri="_uri-to-get-this-specific-uuid-resource_"> _uuid_value_ </uuid>
  <publicInterface uri="_uri-to-interface_" 
	     type="soap | xml-rpc" 
             rdf:about="uri-to-description" /> 
</accessInfo>
<resourceMetaData>  
   human contact for resource ....
   <creationDate date="_time_date_" />
   <lastModified date="_time_date_" />
   <authority>
      creator url for organiation
      creator of data
      <organization> ..... </organization>
      <copyright> ..... </copyright>
      digital signature / signing 
   </authority>
   <pics-rating> .... </pics-rating>
</resourceMetaData>
<syndicationRules> 
   <start-date> ... </start-date>
   <stop-date> ... </stop-date>
   <update interval="xxx" />
   <distribution>
   </distribution>
   <accessControl>
   </accessControl>
<overview> 
    <keywords separator=""> </keywords>
    <category weight="100"> a/b/c </category>
    <category weight="40"> d/e/f </category>
    <desc> _a brief-text-description-of-the-resource_</des>
</overview>

<messageData> 
   .. the actual data being sent ..... 
 
</messageData>