Containers (synonym: collection) are objects that hold multiple Entries for any purpose.
Container here only serves to represent the fact that an Entry finds itself in the company of other Entries.
The container is not defined here beyond its property of containing multiple entries, so other behaviors are open.
Containers represent conceptual base class for weblog, archive, syndication feed, thread, ...
For comparison, DublinCore suggests a different(?) model for "containers". Instead of thinking of "an entry is a container of other things", DublinCore treats all resources as "equals". "Containment", per se, is supported by relating an entry to other entries, including, depending on direction, 'isPartOf' or 'hasPart', and 'isReferencedBy' or 'references'.
Containers work the same way. A Container and Entry are peer resources. An Entry is Related to the Container; the relation is "containedBy".
Yes, an Entry can be a Container because it can be Related to multiple Entries, but that's not the goal here. Container is defined here only as a way to allow an Entry to relate indirectly to other Entries that share the same Container.
JasonHx In an Entry-based storage layer, Containers == functional axes in the application == Controllers in MVC terms. Keep in mind that some containers that people may be thinking of are artifacts of the capital-v View. All of the containers above are describable in XPath-like syntax from either the virtual root node of a collection or a given entry:
|Container Use-cases||Non-normative pseudocode containers|
|Current entry notices from one author, like a weblog feed||entry.author.entry(*).since(time)|
|Current entries from one author, like a weblog front page||entry.author.recent(5)|
|Archive entries from one author, like a weblog archive||entry.author.entry(*).sincethrough(starttime, stoptime)|
|Current entries from several authors constituting a thread||entry/#(*).recent(20)|
|An arbitrary group of related entries, like a list or outline.||entry/#list|
|An export file for transferring entries to another host||entry/*?style=csv.xsl|
To generalize, other Containers aren't so obvious but fit the pattern
Results of a search engine query
All entries by author X, anywhere
Word of mouth, so to speak
Citation in another entry
Hypothetical trigger mechanisms, say situational business advice invoked by rules
Hypothetical inference mechanisms, semantic search
Container compared to EchoFeed
[Skware] +1 on this. This matches my thinking over the last few days it relegates the orginisation of the blog to the CMS, allowing things like date archives, heirarchical categorisation, ... to be used. This possibly combined with something similar to Related would easily allow a photoblog that shows multiple photos in a collection, but still allow comments / permalinks to individual entries. It matches human nature to be able to think of a photo album more conceptually than a particular photo. For instance: people remember that the photo they want is in the birthday party collection of photos, rather than remembering that it was the 6th photo taken on the 24th of June 2003.)
[MikeD] How does a 'container' differ from a 'collection'? What happens to each Entry within a Container when you delete the Container? Are there two kinds of Container resources - one that removes contained Entries and one that does not?
[ZhangYining] removal of a container should not remove the entries that were contained in it, coz an entry can be contained in multiple containers.
The definition of Entry assumes that an Entry will never be deleted ie "permalink".
Collection is a synonym for Container.
[PhilWolff] Can a container hold/cite things besides an Echo entry?
This behavior is open, though using Related Entries would have one type of "role" with the Container, and other things would have a different role.
[BillSeitz] - for sites that don't end up with any feed (e.g. Blogger sites, Zeldman's?), would there be other things that would be helpful, like containing each item within "a name" tags?