hatom-issues

(Difference between revisions)

Jump to: navigation, search
(Entry Summary (atom:summary))
(Entry Content (atom:content))
Line 129: Line 129:
** +1 [[BenjaminCarlyle]]
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[RyanKing]]
 +
** -1 [[ChrisCasciano]]
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion
** -1 [[RyanKing]] - it has a different meaning in Atom, we should avoid the confusion
Line 135: Line 136:
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means.  In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item.  Whereas in hAtom is the thing itself.  The feed is the data is the item.  Thus it makes sense use a different class name than "description".  Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard.  Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means.  In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item.  Whereas in hAtom is the thing itself.  The feed is the data is the item.  Thus it makes sense use a different class name than "description".  Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard.  Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
 +
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
== Entry Summary (atom:summary) ==
== Entry Summary (atom:summary) ==

Revision as of 22:07, 7 February 2006

hAtom issues

Contents


Feed (atom:feed)

RyanKing: STATUS: RESOLVED - 'hfeed'

Initial proposal

atomfeed (or rather, "atom-entry")

Alternatives

The above proposal was not fully accepted and some other possibilities were proposed:

Discussion

The feed is a root class name of hAtom, similar to "vcalendar" in hCalendar, thus it should be fairly unique, per the root class name naming-principles. - Tantek

Entry (atom:entry)

RyanKing: STATUS - RESOLVED - 'hentry'

Initial Proposal

atomentry (or rather, "atom-entry")

Alternatives

The above proposal was not fully accepted. Other alternatives:

Discussion

Entry Title (atom:title)

RyanKing: STATUS - RESOLVED - going with 'headline'

proposals

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

Discussion

Entry Content (atom:content)

Discussion

Entry Summary (atom:summary)

The summary class is defined by vCalendar, iCalendar, hCalendar, and also hReview, to mean "summary or title". Possible alternatives include (add to list):

Discussion

Entry Permalink (atom:link)

STATUS - RESOLVED - 'bookmark'

Discussion

Entry Published (atom:published)

Discussion

Entry Updated (atom:updated)

Discussion

Entry Author (atom:author)

Discussion

Entry Contributor (atom:contributor)

Discussion

Entry Geo (geo:Point)

GeoRSS Resources

Questions and Comments

Limitations

Relationship to hReview definitions needs clarification

[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

Tantek: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

hCards

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

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

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

DavidJanes?: 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.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules: <div class="content"><div class="summary">...</div>...</div>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

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 to new hosting arrangements 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? -- DavidJanes

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?

Dependencies

mfo

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

Is atom:content necessary?

Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

Published as default value for atom:updated

It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:

  1. If multiple updated fields exist, choose the most recent one.
  2. If only one updated field exists, choose that value.
  3. If no updated field exists but a published field exists, use the published value for atom:updated.
+ 1 Robert Bachmann

Designating the page author

(2006-02-07 raised by Robert Bachmann)

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

Proposal

See Also

Template

Please use this format (copy and paste this to the end of the list to add your issues):

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

Views