hatom-brainstorming

hAtom Brainstorming

Brainstorming/discussion of fixes and/or enhancements to hAtom.

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

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

The hAtom 0.1 spec states the follwing 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)