(Difference between revisions)

Jump to: navigation, search
m (hCards)
Line 68: Line 68:
Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- [[DavidJanes]]
Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- [[DavidJanes]]
* [[User:RobertBachmann|Robert Bachmann]]: “MUST” or at least “SHOULD” because atom:author is specified as “The "atom:author" element is a Person construct that indicates the author of the entry or feed.” and <code>&lt;address&gt;</code>’s semantics are to loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;addr class="vcard"&gt;</code> we would have pretty good 1:1 mappings:
** atom:name &harr; hCard’s FN
** atom:email &harr; hCard’s EMAIL
** atom:uri &harr; hCard’s URI
== Comparisons ==
== Comparisons ==

Revision as of 13:02, 26 October 2005


Discussion Participants





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

Goals for hAtom

  1. to provide a blog-post microformat, based on how people actually produce weblogs
  2. based on (1), use Atom as it provides the most suitable data model for doing so
  3. based on (2), to make the format useful anywhere Atom might be used in context to create a syndication feed
  4. provide a baseline envelope format for similar {title|link|content|summary} web pages

Anti-Goals for hAtom

  1. _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


Why 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 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...

Why 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

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 the question remains, does "feed" make sense? (Maybe just naming aesthetics again) -- DannyAyers
I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) -- DavidJanes

Why rel="link" ?

I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the w3c list of rel's, so there is an Occam's Razor case for using this. KevinMarks


Should hCards be required for the <address> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- DavidJanes


This seems precisely analogous to S5:

I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

-- Ernie Prabhakar

See Also

hatom-issues was last modified: Wednesday, December 31st, 1969