hatom-issues: Difference between revisions
Jump to navigation
Jump to search
DannyAyers (talk | contribs) |
DannyAyers (talk | contribs) |
||
| Line 47: | Line 47: | ||
;class="atomfeed" | ;class="atomfeed" | ||
:As above on the atomprefix. But what does 'feed' mean in the context f a HTML page? Doesn't the <head> element cover the corresponding semantics? | :As above on the atomprefix. But what does 'feed' mean in the context f a HTML page? Doesn't the <head> element cover the corresponding semantics? | ||
-- [[DannyAyers]] | |||
It is possible (and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]]) that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking | |||
** I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases | ** I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases | ||
* A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML | * A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML | ||
::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT) | ::This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT) | ||
: The multi-feed point makes sense, but if this data appears on a regular HTML page, does that stiil make sense? (Maybe just naming aesthetics again) -- [[DannyAyers]] | |||
== Comparisons == | == Comparisons == | ||
Revision as of 02:12, 26 October 2005
Discussion Participants
Editors
Authors
Contributors
Purpose
Questions or comments about hAtom go here. Please add your name to the Contributors section above.
Goals for hAtom
- to provide a blog-post microformat, based on how people actually produce weblogs
- based on (1), use Atom as it provides the most suitable data model for doing so
- based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
- Provide a baseline envelope format for similar {title|link|content|summary} web pages
Anti-Goals for hAtom
- _not_ to tell people how to write blogs or what there blog should look like; hAtom marked up blogs should look and behave _identically_ to what they before hAtom was applied
Questions and Comments
Nomenclature
Why atomfeed/atomentry?
- class="atomentry"
- Why not simply "entry"? The parallel to Atom is clear, but in the
context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point. -- DannyAyers
- I choose the "atom" prefix:
- to disambiguate; it is just too likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
- to follow the naming pattern seen in the other "major" microformats (hCard, hCalendar, etc.)
- because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
- I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. Dr. Ernie 16:59, 25 Oct 2005 (PDT)
- DannyAyers My point exactly, but it wouldn't be the end of the world if the prefix was there - not reallly more than aesthetics...
- class="atomfeed"
- As above on the atomprefix. But what does 'feed' mean in the context f a HTML page? Doesn't the <head> element cover the corresponding semantics?
-- DannyAyers
It is possible (and documented) that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
- I'm going to more explicitly recognize that the XHTML document acts as the Feed is many cases
- A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
- This makes sense to me, the way vcalendar is optional since vevent is usually sufficient. Dr. Ernie 16:59, 25 Oct 2005 (PDT)
- The multi-feed point makes sense, but if this data appears on a regular HTML page, does that stiil make sense? (Maybe just naming aesthetics again) -- DannyAyers
Comparisons
This seems precisely analogous to S5:
- atomentry <-> slide
- content <-> slidecontent
- summary <-> handout
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.
See Also
- hAtom - the draft proposal
- hatom-issues - problems? complaints? ideas? Put them here
- hatom-faq - knowledge base
- blog-post-brainstorming
- blog-post-formats
- blog-post-examples
- blog-description-format - how to describe a blog (as opposed to the individual entries, which is what we're doing here)