hatom-issues

(Difference between revisions)

Jump to: navigation, search
(Suggest description as nomenclature for atom:summary)
(summary reserved by hReview)
Line 81: Line 81:
* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be title -> description -> content
* description, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be title -> description -> content
 +
** description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.  [[User:Kevin Marks|Kevin Marks]] 15:51, 31 Dec 2005 (PST)
== hCards ==
== hCards ==

Revision as of 23:51, 31 December 2005

Contents

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

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

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

title reserved by hCard

The title class is reserved by hCard to mean "job title". Possible alternatives include (Please add to list):

summary reserved by hReview

The summary class is reserved by hReview to mean "document title". Possible alternatives include (add to list):

hCards

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

STATUS - RESOLVED. "MAY" is the answer.

Comparisons

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

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

Opaqueness of summary and content

What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. last-modified-brainstorming introduces an idea of using <ins> and <del> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the mfo proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

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.

HTML Title

Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

rel-tag

Should hAtom use rel-tag for atom category elements? A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.

rel-tag uses the last path segment of a URI as its tag, for example <a href="http://apple.com/ipod" rel="tag">iPod</a>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

hAtom2Atom.xsl does not currently supply a scheme. Label is taken from the content of the anchor tag, and no special handling for content such as the title attribute of an img element is performed. Term is the portion of the href after the last slash character.

rel-tag permits url encoding for IRIs, as well as conversion of spaces to plus (+) characters. It is unclear whether the conversion of rel-tag data to atom:category/@term should attempt to reverse any such encoding. The handling of plus characters may be especially difficult to reverse (are the plus characters, or spaces?).

Excess disambiguation rules?

Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

Dependancies

mfo

Does this specification depend on acceptance of a hAtom-compatible mfo?

last-modified

Does this specification depend on acceptance of a hAtom-compatible last-modified?

See Also

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

Views