hatom-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
Line 45: Line 45:
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|hCalendar]], etc.)
** to follow the naming pattern seen in the other "major" microformats ([[hcard|hCard]], [[hcalendar|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
** 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
== Comparisons ==
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html 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=
=See Also=

Revision as of 23:52, 25 October 2005

Discussion Participants

Editors

Authors

Contributors

Purpose

Questions or comments about hAtom go here. Please add your name to the Contributors section above.

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.

class="atomfeed"

As above on the atomprefix. But what does 'feed' mean in the context
of 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
  • 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

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

Retrieved from "http://microformats.org/wiki/index.php?title=hatom-issues&oldid=2355"