Who are the people who would work with the syndicatated data, and how would they work with it? These ideas are fleshed out in this document, which summarizes the nature of the actors who would work with the syndicated data, and the scenarios by which they would interact with this data. THis helps us understand what a syndication system needs to be able to do -- and which a syndication language must support.

1. writer -- a person (or software) that prepares write information to be included as syndicated data in a syndication message. Writer must thus include any data explicitly needed by the syndication format.
2. aggregator -- a person or software system that may aggregate pieces of data and make they available for syndication. This data might be pushed to consumers (after assembly) on a subscription basis, might be pre-packaged for subsequent downloading (by a consumer) or it maybe built on the fly subject to a request by a consumer.
3. consumer -- a person or software system that consumes information provided by an aggregator, and uses that data in some way. Typical ways that a consumer would obtain data include:
   • by requesting a specific data (or set of items) item based on a single identifier for that item (or set of items)
   • by requesting a 'most recent' version of a specific data item (or set of items) based a single identifier for that item (or set of items)
   Note that a consumer can also be an aggregator. That is, a consumer can access data from an aggragator, and then re-aggregate that data and make it available to different consumers.

1. Brief summaries of news articles, with references to 'source' news site (as commonly done with RSS).
2. Complete text of a news article. This data may be in various different XML-related news formats, such as NITF, XMLNews, or in other non-XML formats.
3. Public Event listings. Essentially public calendaring information to be shared amongst different public calendars.
4. Site summary information. Metadata describing content of a site, with referenes to the 'source' of the content. (as commonly done with RSS)
5. Web site content pages. For possible replication of content between different servers/applications.
6. Binary data files (maybe Web site content).

Level 0 Use Cases

By "Level 0" we mean that minimal set of use cases needed for syndication to be possible. Our intention is to design a data model that satisfies Level 0 requirements, but leaves room for future extensions

1. Writer authors data for syndication. Application must ask the author for sufficient additional metadata so that the syndication messages can be constructted successfully.
2. Aggregator assembles data for syndication. Assembly tool must be able to extract (or otherwise obtain) enought inforamtion about each piece of data being assembled to construct a correct syndication message.
3. Aggregator includes aggregated data from another aggregator in the assembled data. The assembly tool must be able to encode this relationship, so that the consumer will know where the different parts of the messages originally come from.
4. Aggregator drops expired data aggregated from elsewhere. The assembly tool must know when such data has exipred, and should no longer be distributed.
5. Consumer requests a specific data item. The consumer must have both an appropriate unique identifier for the data item, plus some understanding of how to obtain that data item.
6. Consumer requests a most-recent version of a specific data item or an entire aggregated message. The consumer must have an appropriate identifier for the data item or the entire message, plus some understanding of how to obtain it.
7. Consumer checks to see when data should be updated. The consumer must know if there is an expiry date (or update interval) for the data it has received
8. Consumer hides data during interval when aggregator says data should be kept hidden . The consumer must know when each piece or aggregated data should 'go public', and when it should be kept hidden.
9. Consumer filters each piece of data based on rating scheme (PICS). The consumer must know the rating scheme for the data blocks it has received.
10. Consumer filters each piece of data based on human language . The consumer must know the human-readable language for the data blocks it has received.
11. Consumer filters each piece of data based on data type of the data . The consumer must know the data type of the data blocks it has received.
12. Consumer contacts aggregator with questions about the aggregation process used to create the data source the consumer has received. Consumer must have appropriate contact information for the aggregator
13. Consumer contacts aggregator to request more complex services (e.g., registers for automatic updating if a new version of an indicated article is released; query the aggregator for a set of articles; etc.) The consumer must know how to contact a software interface to the aggregator, and must know how to find the API for that interface.
    NOTE: The nature of that interface and advanced services is outside the scope of a syndication format specification.

Level 1 Use Cases

These are 'likely' use cases but ones that are either not likely to be needed first out, or whose implementaion is unclear, due to external constraints/ requirements. For example, authenticating a resource requires a working XML digital signature technology, and this is only now being developed

1. Consumer checks authenticity of aggregation messages. Consumer must know location of signature authority it can check with, and must know how to check the messages for authenticity.
2. Consumer organizes/sorts data based on metadata. Consumer must be able to retrieve appropriate metatdata relevant to each data item. Typical metadata would be keyword lists, or category specifications