hAtom Brainstorming

Brainstorming/discussion of fixes and/or enhancements for hAtom 0.2.

Entry Updated Required? -- Blogger Issue

The hAtom 0.1 spec states if there is no Entry Updated element...the page is invalid hAtom I have a real problem with this because I work with Blogger, where we cannot output datetime-design-pattern-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom? -- singpolyma 05:45, 28 Mar 2006 (PST)

• DavidJanes: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example title="day month-name year, hour12:minute ampm tz") but I think this is asking too much from creators and parsers.
  • singpolyma 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats. My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs cannot be parsed by other's hAtom parers as hAtom is now unless they too are so lenient.
  • From experience with authors, I think all properties should be made optional in hAtom 0.2, and hAtom 0.2 must specify how hAtom to Atom converters can synthesize any required elements/attributes in Atom. Tantek 00:02, 26 August 2009 (UTC)
    • JonathanMalek 18:36, 29 August 2009 (UTC): Is there a risk that synthesis of data (for instance, date) could cause trust issues for the entire format? Since the recommendation is that all properties are made optional, then any required property in Atom could be synthesized, which potentially introduces uncertainty/ambiguity into the data. I suppose a counter to that would be that any data is better than no data, which is still better than false or noise data, and so properties should be relaxed to both encourage adoption and reduce noise.

'MAY have multiple Feed elements' -- details and viability of multiple feeds

The hAtom 0.1 spec states the following two items about the Feed element:

1. the Feed element is optional and, if missing, is assumed to be the page
2. hAtom documents MAY have multiple Feed elements

I'm concerned about the implementation details of multiple feeds and that the current 0.1 spec isn't sufficient to define multiple distinct feeds in a single html document and that even if some of those areas were modified if there are real mechanisms out there to support a document with multiple feeds.

To provide examples of how multiple feeds might reside in a document under hAtom 0.1 I've created this collection of hAtom multiple feed tests

Some of the questions that need to be answered (more details and some conclusions at a later time):

1. Can a unique reference be made to each feed? Are there ambiguous references?
2. Can a unique label or feed name be generated from each feed for the purpose of selection by the subscriber?
   • Using the feed title seems to be an option. It is likely (thought not guaranteed) that it is unique.
3. What changes need to be made to the spec to make the publishing of multiple feeds in a document less ambiguous?
   • Robert Bachmann (2006-05-23): IMO the simplest soultion would be to require that each feed element MUST have an XHTML id attribute.
4. What rules are needed for the detection, selection and consumption of feed documents so that people can select and maintain a subscription to the proper feed?
5. How should a consuming application deal with potential changes to feeds found in a document over time (either id changes, additional feeds added, removal of feed, etc)? (this issue could be generalized to single feed documents as well)
6. Chris Casciano (2006-07-24): A good chat session on this issue can be found here

Draft Rules for multiple feeds

(2006-07-24): Written by Chris Casciano

• If there is only one feed on a page spec+parsing rules from 0.1 apply
• If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
• Specific feeds can be addressed via their fragment id.
• If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

Discussion of Draft Rules

• Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
• Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
• Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
• Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)
• Chris Casciano's rules for multiple feeds look good to me, and I agree with their inclusion in hAtom 0.2. - Tantek 00:02, 26 August 2009 (UTC)

User comment entries

A user comment (e.g., in blogs, wikis, forms) can be marked as an hAtom since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing in-reply-to from Atom Threading Extensions. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:

<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>

hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).

hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)

By reusing in-reply-to, we can solve the microformats representation for user comments [1], [2], [3].

--Sarven Capadisli 21:25, 3 Oct 2008 (PDT)

• I like Sarven's approach to comment entries. - Tantek 00:02, 26 August 2009 (UTC)
• See also the comment microformats effort, and perhaps incorporate that analysis here.

url uid properties

Proposal: add the "url" and "uid" properties as another way for authors to indicate a post permalink (in addition to hAtom's use of rel-bookmark).

The use of rel-bookmark works well for re-use and harmonizes nicely with Atom. However, there are some reasons that it would be nice to also have an explicit "url" property for inclusion of URLs to media item resources:

• In MediaWiki - it is difficult to set the "rel" attribute on a link, and thus it is helpful to have the alternative of using class="url" instead.
• The url property is already well used and understood by authors in hCard, hCalendar, hReview, etc.

How it would work:

If there is no rel-bookmark for an hEntry, then an element with property names of "url" and "uid" would be used to determine the permalink for the hEntry.

Tantek 00:02, 26 August 2009 (UTC)

• I started trying to mark up hEntry items on the microformats wiki, and ran into this need. - Tantek 00:02, 26 August 2009 (UTC)

geo for georss

Per an issue raised originally by Brian Suda in hcard-issues:

• 2006-02-03 raised by Brian
  1. We can use the geo microformat in hatom to represent GeoRSS element
     • ACCEPTED DOCUMENTATION. Yes, this should be documented in hatom-examples, perhaps after some hatom-brainstorming about how authors should do it and how hAtom processors should process it. -Tantek

HTML5 time element

hAtom 0.2 should explicitly recommend the preferred use of the HTML5 <time> element for all datetime properties, e.g. "published" and "updated", especially in concert with the value-class-pattern:

<span class="published">
  <time class="value">1:02</time> on <time class="value">2011-07-14</time>
</span>

real-world example from: http://tantek.com/2011/195/t2/google-profiles-support-hcard-rel-me-microformats

see also

• hAtom
• hatom-issues