hatom-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(→‎Comparisons: cleaned up some conversation)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(211 intermediate revisions by 35 users not shown)
Line 1: Line 1:
'''I (RyanKing) am currently working on reorganizing this page. Please hold off on adding new issues or discussion until I'm done. Thanks.'''
{{DISPLAYTITLE: hAtom issues }}
These are externally raised issues about [[hAtom]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.  


= hAtom issues =
'''IMPORTANT''': Please read the [[hatom-faq|hAtom FAQ]] and the [[hatom-issues-resolved|hAtom resolved issues]] ''before'' giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.


== Feed (atom:feed)==
Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — [http://tantek.com/ Tantek]


=== Initial proposal ===
== closed issues ==
See: [[hatom-issues-closed]]


<code>atomfeed</code> (or rather, "atom-entry")
== resolved issues ==
See: [[hatom-issues-resolved]]


* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
== issues ==
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|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
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
* [[DavidJanes]]: 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
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
* [[DannyAyers]]: 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)
* [[User:DavidJanes|David Janes]] 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.) --
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".


'''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.
===2010===
==== No defined parsing rule for <code>updated</code> timestamps in <code>ins</code>elements ====
* {{OpenIssue}} 2010-01-20 raised by [[User:BenWard|BenWard]]
*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456>
*#* Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value.
*#** +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC)
*#* This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC)
*#* Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value.
*#** +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property.  Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC)


[[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
<div class="hentry">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="published">2010-03-20</span>
raised by <span class="fn">[[User:Singpolyma|Singpolyma]]</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">Should we talk about parsing of &lt;time&gt; element?</strong>. I use this element to mark up published on my blog.  It is not supported by any implementation that I know of.  Should implementors be encouraged to add this?  Should the spec talk about it as an alternative to datetime-design-pattern?  That page currently says to check the hcal issues, but there is nothing there about it.
** Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC)
</div>
</div>


* atom-feed
===2009===
* hfeed
==== too many required hentry properties ====
* {{OpenIssue}} 2009-05-26 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement.  A few similar/overlapping/sub-issues are noted below (e.g. [[#Author|author is required]], and not always available).
*#* Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to  mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
*#** consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps ''only'' require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
*#* I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --[[User:Simon Brodtmann|Simon Brodtmann]] 00:51, 1 July 2009 (UTC)
*#** entry:author should be optional and could be either a hCard or a string
*#** entry lacks a [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.category category] and it shuld either use rel-tag or just be a string
* 2009-07-18 [[User:DavidJanes]] I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
* 2009-07-21 [[User:TobyInk|TobyInk]]: Why not have three levels of property: ''required'', ''recommended'' and ''optional''. There would be as few as possible ''required'' properties. Any properties which are needed to create a conformant application/atom+xml feed would be ''recommended''. Everything else would be ''optional''.'
** 2009-07-02 [[User:DavidJanes]] why not then use the RFC MUST, SHOULD and MAY terminology? I think this is a good idea though.
** 2009-09-03 [[User:Chris Cressman|Chris Cressman]] +1 to the idea of property "levels" and reusing RFC terminology.


=== Alternatives ===
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]] but not recommended.
*** +1 [[User:Bmearns|Bmearns]] I think this format has much broader application without this limitation. I'm thinking, for instance, of the Facebook news feed, or a twitter feed, both of which could use this microformat but do not in general have titles for each post.
*** ... your vote here ...
** if this element is not in the [[hatom#In_General|physical model]], the logical model value should be
*** the empty string
**** +1 [[User:DavidJanes]]
**** -1 [[User:WebOrganics|Martin McEvoy]]
*** the value should not be blank.
**** +1 [[User:WebOrganics|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled.
**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
***** [[User:WebOrganics|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
*** the value should be NULL.
**** +1 [[User:Bmearns|Bmearns]]: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate <code>&lt;H1&gt;&lt;/H1&gt;</code>, as opposed to just omitting the title all together.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:Bmearns|Bmearns]]


The above proposal was not fully accepted and some other possibilities were proposed:
==== updated optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]] ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
*** +1 [[User:Chris Cressman|Chris Cressman]] Agree there is demand for optionality. This requirement has previously deterred me from using hAtom.
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
**** +1 [[User:Chris Cressman|Chris Cressman]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]


* <code>feed</code> (Atom consistency)
==== author optionality ====
* <code>atom-feed</code> (Atom consistency with prefix)
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
* <code>hfeed</code> (h* uF consistency)
** this element should be optional
** +1 DavidJanes
*** +1 [[User:DavidJanes]] for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
** +1 Tantek
*** +1 [[User:Chris Cressman|Chris Cressman]] Same reason as 'updated' above.
** +1 BenjaminCarlyle
*** ... your vote here ...
** +1 MarkRickerby
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** "anonymous" (somewhat like [[hreview]]), except not explicit
**** +0.5 [[User:DavidJanes]]
**** 0 [[User:Chris Cressman|Chris Cressman]] Using a blog post as an example, I can determine the author from surrounding context. 'Anonymous' doesn't seem like an acceptable solution. However, I don't have the technical expertise to create a better solution and would be willing to accept 'anonymous'.
*** make this implementation defined
*** something constructed from the page's URL & other information
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]


==== Discussion ====
=== 2008 ===
==== add url property to hentry ====
* {{OpenIssue}} 2008-09-10 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 uses [[rel-bookmark]] for permalinks.  Permalinks may not always be hyperlinks or hyperlinkable.  Thus I propose we re-use the <code>url</code> property (from [[hCard]], [[hCalendar]], [[hReview]], etc.) as a sub-property of the <code>hentry</code> property/container/root.
*#* Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
*# {{ToDo}} can anyone provide examples where this would be used? [[User:DavidJanes]]


The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - Tantek
==== misuse of address element ====
* {{OpenIssue}} 2008-06-07 raised by [[User:Tantek|Tantek]]
*# hAtom 0.1 says "an Entry Author element SHOULD be encoded in an <code>&lt;address&gt;</code> element" and "find the Nearest In Parent <code>&lt;address&gt;</code> element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element.  The address element means the ''contact'' for the page or major portion thereof (see [[hcard-faq#Should_I_use_ADDRESS_for_hCards|hCard FAQ: Should I use ADDRESS for hCards]]), which ''may'' also be the ''author'' but is not necessarily.  See [[hcards-and-pages]] for more details on this semantic distinction.
*#* Proposed resolution: Eliminate all requirements and recommended use of the <code>&lt;address&gt;</code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*#** +1 [[User:Chris Cressman|Chris Cressman]] Prefer microformat solutions that don't dictate specific elements.
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]


== Entry (atom:entry) ==
=== 2007 ===
=== initial proposal ===
==== marking up comments ====
* {{OpenIssue}} 2007-11-25 raised by [http://www.wirewd.com/ Ken Wronkiewicz].
*# There's no currently defined way to exactly handle threaded discussions.  I think this is quite useful to have.
*#* The prior art is RFC [http://tools.ietf.org/html/rfc4685 4864].  The microformat solution should map fairly cleanly to this.
* include in hAtom 0.2
** -1 [[User:DavidJanes]] I think hAtom Comments should be a separate spec
*** +1 to David's -1. [[User:TobyInk|TobyInk]] They're in a separate RFC, so should be separate to hAtom too. That said, it would be nice if hAtom had a clear, documented mechanism for creating extensions.
** +1 [[User:Singpolyma|Singpolyma]] Comments are the important "next step" for hAtom.  The proposal I've seen that I most liked was embedding an hfeed in an hentry.
*** [[User:DavidJanes]] would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too


<code>atomentry</code> (or rather, "atom-entry")
==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''[[rel-tag#Tag_Spaces|rel-tag tagspaces]] should map to atom:category schemes''
*#* hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme
*# {{ToDo}} can we get a real-world example mapping of this? [[User:DavidJanes]]


* [[DannyAyers]]: 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.
=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
** +1 [[User:DavidJanes]] - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
** +1 [[User:Chris Cressman|Chris Cressman]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:Chris Cressman|Chris Cressman]]


* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
==== Relationship of rel-bookmark to url+uid ====
** 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.
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.
** 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. [[User:DrErnie|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 really more than aesthetics...
*** '''STATUS - RESOLVED'''. We're going with "entry".
***  [[Tantek]]: This is actually difficult to consider outside the following issue.  In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** hentry
**** vjournal (from RFC 2445 and thus borrowed in effect from [[hcalendar|hCalendar]])


=== alternatives ===
hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of [[uid-brainstorming]] indicates that the [[hCard]] and [[hCalendar]] permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:
The above proposal was not fully accepted. Other alternatives:


* <code>entry</code> (Atom consistency)
1) To leave things as they are. The two permalink concepts are to be kept separate.
** +1 MarkRickerby
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
** +1 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])


==== Discussion ====
2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg &lt;a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.


[[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].
3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.


If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.
* include in hAtom 0.2
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]


Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal.  Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries. To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.
==== Datetime format (atom:<i>updated</i> and atom:<i>published</i>) ====
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]]
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
** 2009-07-20 [[User:DavidJanes]] {{ToDo}} is this moot? can we move this to resolved?


== Entry Title (atom:title) ==
==== Feed <i>id</i> (atom:<i>id</i>) ====
=== proposals ===
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# atom:<i>id</i> is required for atom:feed. Thus it should be available in hAtom to.


The title class is defined by [[hcard|hCard]] to mean "job title". Possible alternatives include (Please add to list):
It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.


* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
* include in hAtom 0.2
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification.  We may want to avoid the use of 'summary' entirely within hAtom.
** -1 [[User:DavidJanes]] not enough development of these ideas yes
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
* <code>heading</code>
* <code>entry-title</code>
* <code>headline</code>
** +1 Tantek
** +1 KevinMarks, as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
** +1 BenjaminCarlyle, atom:entry/title only
** +&frac12; David Janes, atom:entry/title only
** +&frac12; Paul Bryson, redundant?
* <code>title</code> (Atom consistency)
** -1 [[Tantek]].  Already defined to mean something else in [[hcard|hCard]].  The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
** +&frac12; Paul Bryson, clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
** &plusmn;0 DavidJanes see my note below
** -1 Tantek (does not mean the "name" of the post/entry)
** +1 BenjaminCarlyle, atom:feed/title only


=== Discussion ===
==== Feed <i>permalink</i> (atom:<i>permalink</i>) ====
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small>
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
** I'm proposing the following rules:
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
**# a Feed Permalink element is identified by [[rel-bookmark]] at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed <del>SHOULD</del><ins>MAY</ins> have a Feed Permalink
**# a Feed Permalink element represents the concept of an Atom link in a feed.
**# if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
** 2006-04-03 [[User:ChrisCasciano|ChrisCasciano]] - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
** 2006-04-03 [[User:RobertBachmann|Robert Bachmann]]: I've replaced "SHOULD" with "MAY".
** 2006-04-24 [[User:RobertBachmann|Robert Bachmann]]: Maybe we could simplify my proposal to:
*** "''Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI''"
*** IMO this would be good enough for at least 80% of the cases.  
** 2006-04-12 [[User:DavidJanes]]: {{ToDo}} can we find an example of this in the wild and if so we should add it to the -examples page.
** [[User:Singpolyma|singpolyma]] 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't [[rel-home]] make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.


* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others.  See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p>  Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes


* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
==== Feed <i>updated</i> (atom:<i>updated</i>) ====
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
** atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
**# The Feed Updated element is identified by the class name <code>updated</code> at the feed level (inside a Feed element but not inside an Entry element)
* [[PaulBryson]]: I like entry-title for it's clarity. Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity. In this case, it also adds a specificity that could be detrimental in the element's reuse.  Headline feels redundant with "heading", which is what the element should be.  Regardless, this is probably the best of the available choices.
**# If no element with the class name <code>updated</code> is present, use the youngest <code>updated</code> from the feed's entries.
** 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
** 2007-06-20 [[User:MikeKaply]] The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.
*** 2008-03-20 [[User:TobyInk]] Not crazy at all. I've just implemented an hAtom to Atom converter and I do precisely this. Most (useful) hAtom parsers will "go through all 100 entries" anyway, won't they? So why not look for the youngest updated date as part of that loop. The only slight annoyance is that in RFC 4287, the &lt;atom:updated> element must occur before the first &lt;atom:entry> element -- this is easily solved by inserting a placeholder &lt;atom:updated> element, looping through the entries and then going back and filling in the date. This is really, really, '''not''' a difficult thing to implement.


== Entry Content (atom:content) ==
* include in hAtom 0.2
* <code>content</code> (Atom consistency)
** +0.5 [[User:DavidJanes]]
** +1 Tantek
** +1 DavidJanes
** +1 BenjaminCarlyle
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview consistency)


=== Discussion ===
==== Feed <i>title</i> (atom:<i>title</i>) ====
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
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code>
**# a Feed SHOULD have an Feed Title
**# a Feed Title element represents the concept of an Atom feed title
**# if the Feed Title is missing, use
**#* <del>the first <code>&lt;h#></code> element in the Feed, or</del>
**#* the <code>&lt;title></code> of the page, or
**#* assume it is the empty string
** 2006-04-01 [[User:ChrisCasciano|ChrisCasciano]] - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <code>&lt;title></code> before h# would be prefered if not the most common desire of the page author.
** 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code>&lt;h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code>&lt;h#></code> to encode the date for a group of postings
** 2006-04-12 [[User:DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
** 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
** 2007-02-26 [[User:MikeKaply|Mike Kaply]]: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.


BenjaminCarlyle: We may also have to consider forms of blogs that carry other media. An <a rel="content" href="..."/> 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.
==== Feed <i>author</i> and Entry author (atom:<i>author</i>) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules for Feed author:
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element)
**# a Feed Author element represents the concept of a Atom author
**# a Feed Author element MUST be encoded in a [[hcard|hCard]]
**# a Feed Author element SHOULD be encoded in a <code>&lt;address></code> element
**# a Feed MAY have more than one Feed Author elements
**# if the Feed Author is missing
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code>&lt;address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise <del>the Feed is invalid hAtom</del> <ins>there is no Feed Author</ins>
** I'm proposing the following rules for entry author:
**# an Entry Author element is represented by class name <code>author</code>
**# an Entry Author element represents the concept of an Atom author
**# an Entry Author element MUST be encoded in an [[hcard|hCard]]
**# an Entry Author element SHOULD be encoded in an <code>&lt;address></code> element
**#<del> If a Feed has no Feed author each Entry MUST have at least one Entry Author element</del>
**# <ins>If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
**#* find the [[algorithm-nearest-in-parent|Nearest In Parent]] <code>&lt;address></code> element(s) with class name <code>author</code> and that is/are a valid [[hcard|hCard]]
**#* otherwise the Entry is invalid hAtom</ins>
**# an Entry MAY have more than one Entry Author elements
** [[User:Singpolyma|singpolyma]] 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author.  Also, one or more entries may be missing an author IF feed-level has an author.
** 2006-04-17 [[User:RobertBachmann|Robert Bachmann]]: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"


== Entry Summary (atom:summary) ==
==== Entry <i>id</i> (atom:<i>id</i>) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries.
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html].


The summary class is defined by vCalendar, iCalendar, [[hcalendar|hCalendar]], and also [[hreview|hReview]], to mean "summary or title". Possible alternatives include (add to list):
==== Author ====
===== author as an hcard is too much to require =====
The following 3 items were extracted from the conversation starting on irc with [http://rbach.priv.at/Microformats-IRC/2006-03-24#T152248 logs available starting around here]


* <code>description</code>, 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 summary (atom:title) -> description (atom:summary) -> content (atom:content)
* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.
** [[User:Kevin Marks|Kevin Marks]]: 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.
** [[Tantek]] I don't believe the "can't possibly" statement.  Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL. "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
** [[User:ChrisCasciano|ChrisCasciano]] details of Fil's extraction [http://rbach.priv.at/Microformats-IRC/2006-03-24#T153453 in irc logs] including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
** [[User:Fil|Fil]] the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.


* <code>summary</code> (re-use from and consistency with Atom)
* [[pnhChris]] i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
** [[Tantek]] 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
* <code>partial-description</code>
** [[User:ChrisCasciano|ChrisCasciano]] Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
* <code>excerpt</code>
***[[User:Phae|Frances]] - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person.  Some use may be regained when URL to specific team/information is included, in this circumstance.
** +1 Tantek
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
** +1 BenjaminCarlyle
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good
** +1 DavidJanes, my only concern being that they're not always excerpts
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code>
* <code>abstract</code>
** +1 KevinMarks


=== Discussion ===
* require author as [[hCard]] (i.e. no change from 0.1)
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
** +2 [[User:DavidJanes]]
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making  it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.


* [[Tantek]]: Benjamin is correct.  The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
==== Entry <i>source</i> (atom:<i>source</i>) ====
** WordPress user interface calls it "excerpt"
* raised by [[User:Kevin Marks|Kevin Marks]]
** MovableType user interface calls it "excerpt"
** When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter.  Atom should have chosen "excerpt" as well based on this reason alone.
*** 2009-07-20 [[User:DavidJanes]] {{ToDo}} we need an example of how this would look in the real world


== Other Questions and Issues ==
General comments, modeling issues, algorithm issues, should have issues, etc. go here.


== Entry Permalink (atom:link) ==
=== Entry Updated Required? -- Blogger Issue ===
* <code>rel="bookmark"</code> (HTML consitency)
moved to [[hatom-brainstorming]]
** +2 DavidJanes
** +1 Tantek
** +1 BenjaminCarlyle
** +1 KevinMarks


=== Discussion ===
=== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ===
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
moved to [[hatom-brainstorming]]


* [[DavidJanes]]: 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
== pre 0.1 issues ==
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
'''This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section'''
* [[Tantek]]: 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.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
**  [[RyanKing]] non-issue, you can always use both.


== Entry Published (atom:published) ==
See: [[hatom-issues-pre-0.1]]
* <code>published</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
** +1 BenjaminCarlyle
* <code>dtpublished</code> (Atom consistency with "dt" unofficial pattern)
* <code>VJOURNAL CREATED</code>


=== Discussion ===
== Template ==
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
{{issues-format}}
 
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user.  IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system.  It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
 
== Entry Updated (atom:updated) ==
* <code>updated</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
* <code>dtupdated</code> (Atom consistency with "dt" unofficial pattern)
** +&frac12; Paul Bryson, Not as human readable
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** dtstamp
** dtupdated
 
=== Discussion ===
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
* [[Tantek]]: See discussion for published.  Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something.  Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
* [[DavidJanes]]:  we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
 
== Entry Author (atom:author) ==
* <code>author</code> (Atom consistency)
** +1 Tantek
** +1 BenjaminCarlyle
 
=== Discussion ===
BenjaminCarlyle: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
 
My point is that in practice (>80% case again), contributor is not used.  Thus we should exclude it from hAtom in the first version.  However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later. -Tantek
 
== Entry Contributor (atom:contributor) ==
** -1 Tantek
* <code>contibutor</code> (Atom consistency)
** +1 Tantek
** +1 DavidJanes
 
=== Discussion ===
I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor".  We should reserve the name so we can add it later if we need it (thus the +1 on "contributor"). -Tantek
 
DavidJanes: deferred
 
== Questions and Comments ==
 
=== Limitations ===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.
 
=== Nomenclature ===
 
'''I'm working on merging this section with the discussion above.''' --[[User:RyanKing|RyanKing]] 11:35, 1 Feb 2006 (PST)
 
==== Relationship to hReview definitions needs clarification ====
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:
 
* atom:published -> hReview dtreviewed
* atom:author    -> hReview reviewer
 
"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.
 
- Tantek
 
=== hCards ===
 
Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please -- [[DavidJanes]]
 
* [[User:RobertBachmann|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 <code>&lt;address&gt;</code>’s semantics are too loose to describe [http://atompub.org/2005/08/17/draft-ietf-atompub-format-11.html#rfc.section.3.2 an Atom person construct] but using <code>&lt;addr class="vcard"&gt;</code> we would have pretty good 1:1 mappings:
** atom:name &harr; hCard’s FN
** atom:email &harr; hCard’s EMAIL
** atom:uri &harr; hCard’s URI
 
'''STATUS - OPEN'''. "MAY" is the answer.
 
Tantek: I think this should be MUST.  Atom should have referenced vCard for these semantics and made the mistake of making up their own terms.  Let's undo that mistake with hAtom.  Also, [[hreview|hReview]] 0.3 is going to make hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]].  Thus we may want to just follow suit with hAtom as well.
 
DavidJanes: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:
 
<pre><nowiki>
<div class="author">bonehead</div>
</nowiki></pre>
 
has an assumed defined mapping to
 
<pre><nowiki>
<div class="author vcard"><span class="fn">bonehead</div></div>
</nowiki></pre>
 
Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmicly.
 
=== Comparisons ===
 
This seems precisely analogous to [http://www.meyerweb.com/eric/tools/s5/xoxo-structure-ref.html 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]]
 
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same.  The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not.  Note that you can overlay hAtom and S5 in the same markup.  Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.
 
=== 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 [[hatom#Nesting_Rules|here]], [[hatom#Entry_Title|here]], [[hatom#Entry_Permalink|here]] and [[hatom#Entry_Published|here]].
 
Your thoughts please... -- [[User:DavidJanes|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 [[hatom#hAtom_Opaque|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
 
* The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. -- [[User:DavidJanes|David Janes]]
 
See the [[mfo-examples]] document, and add further thoughts on this matter there. -- Tantek
 
==== 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 <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> 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:
<code>&lt;div class="content">&lt;div class="summary">...</div>...</div></code>
 
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 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?
 
IMHO yes. -- Tantek
 
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 <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. 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.
 
* This looks like a clear mapping to me - term is last path segment; scheme is the tagspace and label is the text within the anchor? The problem is if the scheme + tag is not a true URL  but a URI. So for your example, term is 'ipod, scheme is 'http://apple.com/' and label is iPod. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
 
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?).
 
* They are spaces. If you want plus characters use %2B Perhaps I should add this to rel-tag. [[User:Kevin Marks|Kevin Marks]] 15:03, 31 Dec 2005 (PST)
 
=== 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:
# If multiple updated fields exist, choose the most recent one.
# If only one updated field exists, choose that value.
# If no updated field exists but a published field exists, use the published value for atom:updated.


== See Also ==
== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-formats]]
Line 392: Line 310:
* [[mfo-examples]]
* [[mfo-examples]]
* [[naming-principles]]
* [[naming-principles]]
== Template ==
Please use this format (copy and paste this to the end of the list to add your issues):
* YYYY-MM-DD raised by [http://yourhomepage.example.com YOURNAME].
*# ''Issue 1: Here is the first issue I have.''
*# ''Issue 2: Here is the second issue I have.''

Latest revision as of 16:23, 18 July 2020

These are externally raised issues about hAtom with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.

IMPORTANT: Please read the hAtom FAQ and the hAtom resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek

closed issues

See: hatom-issues-closed

resolved issues

See: hatom-issues-resolved

issues

Please add new issues to the bottom of the list by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

2010

No defined parsing rule for updated timestamps in inselements

  • open issue! 2010-01-20 raised by BenWard
    1. hAtom includes the updated property for the last modification/revision date of an entry. HTML already has an ins element for marking up inserted changes to text, and that element has a datetime attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that datetime attribute, but the document semantics suggest it would be an appropriate source for the updated property. Example: <http://blog.benward.me/post/250674456>
      • Proposed resolution. Document a parsing rule for the ins element, stating that for an ins (or del) element with class of updated, the value of the datetime attribute should be used as the value.
        • +1 This sounds like a good idea and something worthy of being incorporated into hcard-parsing#more_semantic_exceptions (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. Tantek 17:43, 21 January 2010 (UTC)
      • This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. TobyInk 23:00, 21 March 2010 (UTC)
      • Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where update is not explicitly marked up, the parser may aggregate all ins and del elements in the hentry, and use the most recent datetime attribute content as the updated value.
        • +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. Tantek 17:43, 21 January 2010 (UTC)

open issue! 2010-03-20 raised by Singpolyma

  • Should we talk about parsing of <time> element?. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.
    • Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. TobyInk 23:00, 21 March 2010 (UTC)

2009

too many required hentry properties

  • open issue! 2009-05-26 raised by Tantek
    1. hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement. A few similar/overlapping/sub-issues are noted below (e.g. author is required, and not always available).
      • Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
        • consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps only require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
      • I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --Simon Brodtmann 00:51, 1 July 2009 (UTC)
        • entry:author should be optional and could be either a hCard or a string
        • entry lacks a category and it shuld either use rel-tag or just be a string
  • 2009-07-18 User:DavidJanes I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
  • 2009-07-21 TobyInk: Why not have three levels of property: required, recommended and optional. There would be as few as possible required properties. Any properties which are needed to create a conformant application/atom+xml feed would be recommended. Everything else would be optional.'
    • 2009-07-02 User:DavidJanes why not then use the RFC MUST, SHOULD and MAY terminology? I think this is a good idea though.
    • 2009-09-03 Chris Cressman +1 to the idea of property "levels" and reusing RFC terminology.

entry-title optionality

  • open issue! 2009-07-18 raised by User:DavidJanes
    • this element should be optional
      • +1 User:DavidJanes
      • +1 Martin McEvoy but not recommended.
      • +1 Bmearns I think this format has much broader application without this limitation. I'm thinking, for instance, of the Facebook news feed, or a twitter feed, both of which could use this microformat but do not in general have titles for each post.
      • ... your vote here ...
    • if this element is not in the physical model, the logical model value should be
      • the empty string
      • the value should not be blank.
        • +1 Martin McEvoy see: Required Entry Elements from Atom Enabled.
        • User:DavidJanes what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
          • Martin McEvoy entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
      • the value should be NULL.
        • +1 Bmearns: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate <H1></H1>, as opposed to just omitting the title all together.
      • ... your proposal here, your vote in a sublist ...
  • include in hAtom 0.2

updated optionality

  • open issue! 2009-07-18 raised by User:DavidJanes
    • this element should be optional
      • +1 User:DavidJanes ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
      • +1 Chris Cressman Agree there is demand for optionality. This requirement has previously deterred me from using hAtom.
    • if this element is not in the physical model, the logical model should be
  • include in hAtom 0.2

author optionality

  • open issue! 2009-07-18 raised by User:DavidJanes
    • this element should be optional
      • +1 User:DavidJanes for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
      • +1 Chris Cressman Same reason as 'updated' above.
      • ... your vote here ...
    • if this element is not in the physical model, the logical model should be
      • "anonymous" (somewhat like hreview), except not explicit
        • +0.5 User:DavidJanes
        • 0 Chris Cressman Using a blog post as an example, I can determine the author from surrounding context. 'Anonymous' doesn't seem like an acceptable solution. However, I don't have the technical expertise to create a better solution and would be willing to accept 'anonymous'.
      • make this implementation defined
      • something constructed from the page's URL & other information
      • ... your proposal here, your vote in a sublist ...
  • include in hAtom 0.2

2008

add url property to hentry

  • open issue! 2008-09-10 raised by Tantek
    1. hAtom 0.1 uses rel-bookmark for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the url property (from hCard, hCalendar, hReview, etc.) as a sub-property of the hentry property/container/root.
      • Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
    2. to do! can anyone provide examples where this would be used? User:DavidJanes

misuse of address element

  • open issue! 2008-06-07 raised by Tantek
    1. hAtom 0.1 says "an Entry Author element SHOULD be encoded in an <address> element" and "find the Nearest In Parent <address> element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element. The address element means the contact for the page or major portion thereof (see hCard FAQ: Should I use ADDRESS for hCards), which may also be the author but is not necessarily. See hcards-and-pages for more details on this semantic distinction.
      • Proposed resolution: Eliminate all requirements and recommended use of the <address> element from hAtom.
  • include in hAtom 0.2

2007

marking up comments

  • open issue! 2007-11-25 raised by Ken Wronkiewicz.
    1. There's no currently defined way to exactly handle threaded discussions. I think this is quite useful to have.
      • The prior art is RFC 4864. The microformat solution should map fairly cleanly to this.
  • include in hAtom 0.2
    • -1 User:DavidJanes I think hAtom Comments should be a separate spec
      • +1 to David's -1. TobyInk They're in a separate RFC, so should be separate to hAtom too. That said, it would be nice if hAtom had a clear, documented mechanism for creating extensions.
    • +1 Singpolyma Comments are the important "next step" for hAtom. The proposal I've seen that I most liked was embedding an hfeed in an hentry.
      • User:DavidJanes would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too

atom:category scheme

  • open issue! 2007-06-01 raised by Ryan King.
    1. rel-tag tagspaces should map to atom:category schemes
      • hAtom already defines how to map term and label. It seems that the tagspace can easily map to scheme
    2. to do! can we get a real-world example mapping of this? User:DavidJanes

2006

Geo

  • open issue! 2006-02-03 raised by BrianSuda
    • We can use the geo microformat in hatom to represent GeoRSS element
    • +1 User:DavidJanes - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
    • +1 Chris Cressman
  • include in hAtom 0.2

Relationship of rel-bookmark to url+uid

The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.

hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of uid-brainstorming indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:

1) To leave things as they are. The two permalink concepts are to be kept separate.

2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.

3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.

  • include in hAtom 0.2

Datetime format (atom:updated and atom:published)

  • 2006-05-23 raised by Robert Bachmann
    • Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
      • ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
    • 2009-07-20 User:DavidJanes to do! is this moot? can we move this to resolved?

Feed id (atom:id)

  • open issue! 2006-04-01 raised by Robert Bachmann
    1. atom:id is required for atom:feed. Thus it should be available in hAtom to.

It is suggested the Feed permalink should be used as the feed ID, however a piece by Mark Pilgrim (http://diveintomark.org/archives/2004/05/28/howto-atom-id) makes arguments against using permalinks and in favour of Tag URIs.

  • include in hAtom 0.2

Feed permalink (atom:permalink)

  • open issue! 2006-04-01 raised by Robert Bachmann
    • I'm proposing the following rules:
      1. a Feed Permalink element is identified by rel-bookmark at the feed level (inside a Feed element but not inside an Entry element)
      2. a Feed SHOULDMAY have a Feed Permalink
      3. a Feed Permalink element represents the concept of an Atom link in a feed.
      4. if the Feed Permalink is missing, use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI
    • 2006-04-03 ChrisCasciano - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
    • 2006-04-03 Robert Bachmann: I've replaced "SHOULD" with "MAY".
    • 2006-04-24 Robert Bachmann: Maybe we could simplify my proposal to:
      • "Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI"
      • IMO this would be good enough for at least 80% of the cases.
    • 2006-04-12 User:DavidJanes: to do! can we find an example of this in the wild and if so we should add it to the -examples page.
    • singpolyma 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't rel-home make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.
  • include in hAtom 0.2

Feed updated (atom:updated)

  • open issue! 2006-04-01 raised by Robert Bachmann
    • atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
      1. The Feed Updated element is identified by the class name updated at the feed level (inside a Feed element but not inside an Entry element)
      2. If no element with the class name updated is present, use the youngest updated from the feed's entries.
    • 2006-04-12 User:DavidJanes I like this. And the definition of "feed level"
    • 2007-06-20 User:MikeKaply The "youngest" thing is a really bad idea. If a page has 100 hAtom entries, a parser would have to go through all 100 looking for a low date. That's crazy.
      • 2008-03-20 User:TobyInk Not crazy at all. I've just implemented an hAtom to Atom converter and I do precisely this. Most (useful) hAtom parsers will "go through all 100 entries" anyway, won't they? So why not look for the youngest updated date as part of that loop. The only slight annoyance is that in RFC 4287, the <atom:updated> element must occur before the first <atom:entry> element -- this is easily solved by inserting a placeholder <atom:updated> element, looping through the entries and then going back and filling in the date. This is really, really, not a difficult thing to implement.

Feed title (atom:title)

  • open issue! 2006-04-01 raised by Robert Bachmann
    • atom:title is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
      1. a Feed Title element is identified by the class name entryfeed-title
      2. a Feed SHOULD have an Feed Title
      3. a Feed Title element represents the concept of an Atom feed title
      4. if the Feed Title is missing, use
        • the first <h#> element in the Feed, or
        • the <title> of the page, or
        • assume it is the empty string
    • 2006-04-01 ChrisCasciano - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using <title> before h# would be prefered if not the most common desire of the page author.
    • 2006-04-05 Robert Bachmann: Okay. Deleted "the first <h#> element in the Feed, or"
    • 2006-04-12 User:DavidJanes Note also in support of this decision that many blogs use <h#> to encode the date for a group of postings
    • 2006-04-12 User:DavidJanes: why entry-title for the feed title. Why not fn or feed-title?
    • 2006-04-12 Robert Bachmann: Sorry, this was a "copy & paste" mistake. Fixed now.
    • 2007-02-26 Mike Kaply: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.

Feed author and Entry author (atom:author)

  • open issue! 2006-04-01 raised by Robert Bachmann
    • I'm proposing the following rules for Feed author:
      1. a Feed Author element is represented by class name author at the feed level (inside a Feed element but not inside an Entry element)
      2. a Feed Author element represents the concept of a Atom author
      3. a Feed Author element MUST be encoded in a hCard
      4. a Feed Author element SHOULD be encoded in a <address> element
      5. a Feed MAY have more than one Feed Author elements
      6. if the Feed Author is missing
        • find the Nearest In Parent <address> element(s) with class name author and that is/are a valid hCard
        • otherwise the Feed is invalid hAtom there is no Feed Author
    • I'm proposing the following rules for entry author:
      1. an Entry Author element is represented by class name author
      2. an Entry Author element represents the concept of an Atom author
      3. an Entry Author element MUST be encoded in an hCard
      4. an Entry Author element SHOULD be encoded in an <address> element
      5. If a Feed has no Feed author each Entry MUST have at least one Entry Author element
      6. If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
        • find the Nearest In Parent <address> element(s) with class name author and that is/are a valid hCard
        • otherwise the Entry is invalid hAtom
      7. an Entry MAY have more than one Entry Author elements
    • singpolyma 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
    • 2006-04-17 Robert Bachmann: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

Entry id (atom:id)

  • open issue!2006-04-01 raised by Robert Bachmann
    • atom:id is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
    • --Federico 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
    • 2006-12-31 response by Emanla Eraton No, it shouldn't be a permalink. It should be a "tag:" id for entries.
    • 2007-06-06 RyanKing - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [1], while tag URIs require them [2].

Author

author as an hcard is too much to require

The following 3 items were extracted from the conversation starting on irc with logs available starting around here

  • Fil If, for example, you are programming an "aggregator" of news syndicated from many sources like in Sedna, chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
    • Tantek I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
    • ChrisCasciano details of Fil's extraction in irc logs including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
    • Fil the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.
  • pnhChris i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
    • Tantek 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
    • ChrisCasciano Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
      • Frances - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
        • User:TobyInk - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
  • Fil for the moment, to comply losely with hAtom 0.1, I will use <span class="author"><span class="vcard"><span class="fn">My Name</span></span></span> ; but it's not good
    • Tantek You can actually simplify that (one fewer span) with: <span class="author vcard"><span class="fn">My Name</span></span>

Entry source (atom:source)

  • raised by Kevin Marks
    • When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
      • 2009-07-20 User:DavidJanes to do! we need an example of how this would look in the real world

Other Questions and Issues

General comments, modeling issues, algorithm issues, should have issues, etc. go here.

Entry Updated Required? -- Blogger Issue

moved to hatom-brainstorming

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

moved to hatom-brainstorming

pre 0.1 issues

This section is more or less closed, as hAtom 0.1 is out the door. If there are open issues that you are championing that didn't make it into hAtom 0.1, move them up above to the hAtom 0.2 section

See: hatom-issues-pre-0.1

Template

Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.

Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.

<div class="hentry">
{{OpenIssue}} 
<span class="entry-summary author vcard">
 <span class="published">2011-MM-DD</span> 
 raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>

See Also