Use Cases

The format should support today's weblog use cases at a minimum. Let's make sure this landscape is covered. See also EntryCatalog.

What are the different kinds of feeds that might exist (give existing examples if available)?

Use Cases and Core

What use cases exercise the core of the ConceptualModel?

What use cases exercise the extensions?


[ZhangYining RefactorOk] Not sure if relevant here, but one Use Case is posting/containing photos (or other forms of arts) in an Entry, a typical example might be a photojournalist who blogs a breaking news that has content and one or multiple illustrating photos. The question would be how to include non-text resources, jpg files in this case, in an Entry, should the weblogger upload jpg files to his home directory at her blog hosting server and reference them in content, or there is an extension mechanism to allow her to post them together with the Entry, or other methods? Whichever method is adopted, how should archiving and syndicating work for such blogs?

[ChrisWilper RefactorOk] No consensus yet on "weblogs only" vs. more innovative forms of syndication. IMO we need to decide which use cases it needs to support, and which might be supported later through extensions.

[DaveWarnock RefactorOk] I would like to be able to use it to provide feeds from [WWW]VisibleResults our free fundraising software for charities. The uses would be a) end users getting news about fundraising projects (typical; RSS, no problem) b) managers tracking what is happening in the system (needs https and basic authentication, could be lot more than 15 items, might need a feed of feeds ie just a list of available feeds) c) trainers tracking what the people they are teaching are doing in the system (security) d) sysadmins checking logs/performance (security) e) public checking on changed to their own data (security).

I guess the key differences from standard blogging are security, much greater number of feeds, larger no of items in a feed, more rapid change of data into feed. But it would be good if there were also some support for a push model for the format, ie a desktop/server application that is fed each event as it happens rather than pulling at intervals.

[JoshJacobs RefactorOk] I'd like to see aggregators be able to 'spider' their way to a macro view of a topic, regardless of entry point. For example I go to a blog entry that references a post on another blog that is being responded to. The original post might in fact be a response to yet another post. Comments exist on multiple blogs, etc. From the point that I discovered the conversation I'd like to be able to tell my aggregator to pull together a more linear view of the conversation, and update it regardless of where new content comes from. This would essentially be a meta subscription, that I could archive for myself. I should have control over granularity (posts only, posts + comments, etc). The other benefit of this approach is that, as often happens, discussions may move between blogs over a period of time. I can respond with a comment to the latest post or comment without having to try to figure out where the current activity has shifted to.

Seperate thought, I think a lot of the discussion to far has been about what a post is, I hope the use case section will start to take on a lot more discussion about how users (as opposed to authors and tool vendors) want to interact with feeds. I'd love to see some of the aggregator vendors weigh in on cool feature ideas they've been unable to implement due to gaps in the available data sets. As Echo rolls out I'm of the belief that the ratio of pure readers, as opposed to authors/readers will be very high (think web browsers to HTML publishers), I think a lot more focus on how to take advantage of the dataverse to enable new user applications is really important. I guess in some ways I see the aggregators being far more important in this conversation than the blogging tools. This is entirely due to the fact that I don't blog, but I read extensively.

[JoshJacobs RefactorOk] Does it make sense to have a separate discussion page for discussion of a subscription data structure? I can envision wanting to be able to leverage post data in defining my subscriptions. Simple use cases include providing credentials to retrieve personalized or secure feeds, if categories are supported I might want to filter categories at the subscription level, for multi-author blogs I might want to control which authors I see or exclude specific posters, etc.) I know that some of this can be done client side by the aggregator, but todays aggregators are using OPML as a subscription import/export format, and it seems appropriate to extend and preserve this capability. Not sure if this is out of scope for the project.

[DeaneBarker] I started a dicsussion ( about how you handle updates to entries (topics, posts, etc.). How do you get updates into an RSS feed? What is the "correct" practice for this? How do you aggregate many posts on the same topic to give a full view of THAT topic in a given blog? There are several comments n it at the above URL.

[AsbjornUlsberg, RefactorOk] One issue I would like to adress, but which I'm not sure is in the scope of Echo (at least not in v1.0), is that news broadcasters would like an easy interchange format that allows them to have control over copyrighted material. SOAP can of course be used, but RSS is already widely adopted, and it would therefore be easier for all news broadcasters to change to a similar, but new, RSS format, than to change to SOAP. Therefore we should look a bit into some handshake techniques, if it's not too difficult to solve. I know SOAP already has solutions for this, so we might just embed some of those into Echo.

I think it would be very useful to keep a subscription-list as a XML document on each site that offers some kind of feed, and then write a really simple interface (XML format + API) for how to get into such a subscription-list. When inside a list one can maybe classify what kind of information each subscriber should get, define different groups with different rights and such, but that's not important in the first place. As long as we define this subscription-mechanism, it should and can be easilly extended with a richer set of criterias and such afterwards.

[MaciejCeglowski] There's a small but significant group of bloggers who write posts in multiple languages [WWW]Marysia Milonas, for example. Many readers in the States might want to filter her blog on English posts only - this is a use case that is not served by the format as I understand it right now.

[NickChalko RefactorOk] UseCaseNamingGuidelines. I recommend the pattern of "Name Use Case", all as one word of course.

[KenMacLeod, RefactorOk] I'm the one who put "LINKS PLEASE" on the use-case list. These types of sites appear to have or would have a VERY strong influence on the core conceptual model. These kinds of sites aren't in my blogroll, I don't know what sites to add. The examples we need are ones that exist today, so we can see how they work today, not proposals or ideas that we would need to invent solutions for.

[AllenFirstenberg, RefactorOk] I just added the "current lists" item as an example of some resources that can use RSS now that wouldn't under the proposal to require a date stamp for every item. In these cases, each item would either have the same published date stamp, or would have date stamps that should not be used to indicate the ordering.

[BillSeitz] - while I think most blogging environments would make it easier to edit a BlogRoll, I think the bigger issue is how to identify them on front page [Containers] so that those links can be considered separately from the links in the list-of-latest-entries...

[AlexanderPayne + PhilLeif RefactorOk] Seconded: the syndication file/feed should include a reference to a BlogRoll (or another "related materials" list) owned by the blog's author. This would make finding blogrolls infinitely easier, and help to facilitate interconnection between blogs and their respective authors. In addition, this could provide a foundation for a reputation system.

[WWW]Use Cases Tutorial

See BlogRoll, Usability

CategoryProject, CategoryModel, CategoryRss