hatom-issues

From Microformats Wiki
Revision as of 14:56, 27 December 2005 by FuzzyBSc (talk | contribs) (Add: Opaqueness of other microformat elements)
Jump to navigation Jump to search

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

  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

Nomenclature

Why 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 (David Janes) 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...

STATUS - RESOLVED. We're going with "entry".

Why atomfeed?

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
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.) -- David Janes

STATUS - PARTIALLY RESOLVED. We're going with "feed" IF and when the Feed element is used. When and where Feed is used at all is still under discussion in the mailing list as of 2005-12-26.

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

  • I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion -- DavidJanes
  • Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom -- DavidJanes
  • Agreed with what Kevin wrote. Also, rel="link" doesn't actually make sense when you do the analysis as described in the rel-faq. The destination of the link is not really a "link" itself with respect to the current document/file. - Tantek
  • OK, I'm happy with this -- David Janes

STATUS - RESOLVED. We are using class="bookmark".

hCards

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

  • 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 <address>’s semantics are too loose to describe an Atom person construct but using <addr class="vcard"> we would have pretty good 1:1 mappings:
    • atom:name ↔ hCard’s FN
    • atom:email ↔ hCard’s EMAIL
    • atom:uri ↔ hCard’s URI

STATUS - RESOLVED. "MAY" is the answer.

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.

-- Ernie Prabhakar

  • See the #Purpose section above. Basically that drove the design decision for the naming David Janes

STATUS - RESOLVED. We're sticking with atom terminology (entry, content, summary).

Repeated Elements

We allow certain elements to be repeated, such as Entry Permalink, Entry Published and Entry Title, even though there can be at most one real value. We provide "disambiguation" rules for sorting out which is the real value. See here, here, here and here.

Your thoughts please... -- David Janes

STATUS - RESOLVED. The spec has explicit rules for disambiguating all these items if they appear multiple times.

Opaqueness

If you have concerns about opaqueness, that is, stopping interpretation below certain hAtom elements, raise them here.

Opaqueness of other microformat elements

How would we handle a case where someone wanted to provide a vcard under the class=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise, Is it possible that other microformats found under the class=entry or class=feed elements need to be considered opaque?

-- BenjaminCarlyle

Identification

The current spec under Schema:Nomenclature:Entry includes the text: "if practical, also define id="unique-identifier" to the Entry" What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog t new hosting arragements and the like. Are current feed URLs or even rel=bookmarks solid enough?

STATUS - OPEN.

See Also

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