Microformats Wiki - User contributions [en]

hatom-issues

2009-08-03T11:25:37Z

DavidJanes: Added commnet on MUST, etc.

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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.

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed title (atom:title) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T20:53:35Z

DavidJanes: /* marking up comments */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

=== 2007 ===
==== 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 [[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

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

=== 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?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)
** -1 [[User:Singpolyma|Singpolyma]]

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed title (atom:title) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:50:10Z

DavidJanes: added voting section

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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.

* include in hAtom 0.2
** +0.5 [[User:DavidJanes]]

==== Feed title (atom:title) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:49:13Z

DavidJanes: added voting section

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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.

* include in hAtom 0.2
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:48:04Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:47:48Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:47:31Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:47:07Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:46:52Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:46:28Z

DavidJanes: Changed depth of final point

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
* include in hAtom 0.2
** +1 [[User:DavidJanes]]
** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:45:27Z

DavidJanes: Need example

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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]] {{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 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:43:17Z

DavidJanes: Added voting section

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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
** -1 [[User:DavidJanes]] not enough development of these ideas yes

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:41:43Z

DavidJanes: added voting section

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

* require author as [[hCard]] (i.e. no change from 0.1)
** +2 [[User:DavidJanes]]

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:37:54Z

DavidJanes: Is this point moot?

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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?

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-20T10:36:11Z

DavidJanes: In hAtom 0.2?

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== 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.
*** ... 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.
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** -1 [[User:DavidJanes]] (let's wait for resolution elsewhere, also would need real world examples)

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T15:03:51Z

DavidJanes: /* entry-title optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]
*** ... 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?
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]
*** +1 [[User:WebOrganics|Martin McEvoy]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T14:00:53Z

DavidJanes: /* Geo */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 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?
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:54:19Z

DavidJanes: /* atom:category scheme */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:53:56Z

DavidJanes: /* marking up comments */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

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

==== 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
*# can we get a real-world example mapping of this? {{ToDo}} [[User:DavidJanes]]

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:52:52Z

DavidJanes: /* atom:category scheme */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

=== 2007 ===
==== 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.

==== 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
*# can we get a real-world example mapping of this? {{ToDo}} [[User:DavidJanes]]

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:36:36Z

DavidJanes: removed ToDo label

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

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

==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:35:12Z

DavidJanes: /* misuse of address element */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)
*#** +1 [[User:DavidJanes]]
*# include in hAtom 0.2
*#* +1 [[User:DavidJanes]]

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

Template:ToDo

2009-07-18T13:33:36Z

DavidJanes:

to do!

hatom-issues

2009-07-18T13:28:59Z

DavidJanes: /* author optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
*** ... your vote here ...
** 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]]
*** 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]]

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:27:28Z

DavidJanes: /* updated optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be
*** the page creation date
**** +1 [[User:DavidJanes]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== author optionality ====
* {{OpenIssue}} 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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:26:50Z

DavidJanes: /* entry-title optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
** this element should be optional
*** +1 [[User:DavidJanes]]
*** ... 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]]
*** ... your proposal here, your vote in a sublist ...
** include in hAtom 0.2
*** +1 [[User:DavidJanes]]

==== 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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:24:32Z

DavidJanes: /* add url property to hentry */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== 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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:21:43Z

DavidJanes: /* author optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== 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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:21:13Z

DavidJanes: /* updated optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== 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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:20:53Z

DavidJanes: /* entry-title optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 [[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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:20:05Z

DavidJanes: /* author optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 [[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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[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
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** "anonymous" (somewhat like [[hreview]], except not explicit
** make this implementation defined
** something constructed from the page's URL & other information
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:13:31Z

DavidJanes: /* updated optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 [[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
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** the page creation date
*** +1 [[User:DavidJanes]]
** ... your proposal here, your vote in a sublist ...

==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T13:09:42Z

DavidJanes: /* entry-title optionality */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** +1 [[User:DavidJanes]]
** ... 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]]
** ... your proposal here, your vote in a sublist ...

==== updated optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...
==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-issues

2009-07-18T12:09:25Z

DavidJanes: /* too many required hentry properties */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}
==== entry-title optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...
==== updated optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...
==== author optionality ====
* {{OpenIssue}} 2009-07-18 [[User:DavidJanes]]
* this element should be optional
** ... your vote here ...
* if this element is not in the [[hatom#In_General|physical model]], the logical model should be
** ... your proposal here, your vote in a sublist ...

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

hatom-tracking

2009-07-18T12:02:40Z

DavidJanes: New page: <entry-title> hAtom tracking </entry-title> This wiki page is to track what has to be done for create the next version of hAtom. This should mostly be links to other places in the Wiki and...

<entry-title> hAtom tracking </entry-title>
This wiki page is to track what has to be done for create the next version of hAtom. This should mostly be links to other places in the Wiki and will give an "at-a-glance" status update to the project - eschew content on this page

== hAtom 0.2 ==

* started: 2009-07-18
* issues:
** [[hatom-issues#|too many required hentry properties]] (open)
** [[hatom-issues#|add url property to hentry]] (open)
** [[hatom-issues#|misuse of address element]] (open)
** [[hatom-issues#|marking up comments]] (open)
** [[hatom-issues#|atom:category scheme]] (open)
** [[hatom-issues#|Geo]] (open)
** [[hatom-issues#|Relationship of rel-bookmark to url+uid]] (?)
** [[hatom-issues#|Datetime format (atom:updated and atom:published)]] (?)
** [[hatom-issues#|Feed id (atom:id)]] (open)
** [[hatom-issues#|Feed permalink (atom:permalink)]] (open)
** [[hatom-issues#|Feed updated (atom:updated)]] (open)
** [[hatom-issues#|Feed title (atom:title)]] (open)
** [[hatom-issues#|Feed author and Entry author (atom:author)]] (open)
** [[hatom-issues#|Entry id (atom:id)]] (open)
** [[hatom-issues#|Author]] (?)
** [[hatom-issues#|Entry source (atom:source)]] (?)

hatom-issues

2009-07-18T12:01:27Z

DavidJanes: /* too many required hentry properties */

<entry-title> hAtom issues </entry-title>
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|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.

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]

== 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|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

===2009===
==== 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 {{ToDo}}

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

==== 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><address></code> element" and "find the Nearest In Parent <code><address></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><address></code> element from hAtom.
*#** +1 --[[User:Csarven|Sarven Capadisli]] 11:57, 11 Nov 2008 (PST)

=== 2007 ===
==== 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.

==== atom:category scheme ====
* {{OpenIssue}} 2007-06-01 raised by [http://theryanking.com/ Ryan King].
*# ''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

=== 2006 ===
====Geo====
* {{OpenIssue}} 2006-02-03 raised by [[BrianSuda]]
** We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element

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

==== Datetime format (atom:updated and atom:published) ====
* 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

==== Feed id (atom:id) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
*# 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.

==== Feed permalink (atom:permalink) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** I'm proposing the following rules:
**# 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]]: 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.

==== Feed updated (atom:updated) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
**# 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)
**# 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 <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) ====
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]
** atom:title 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><h#></code> element in the Feed, or</del>
**#* the <code><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><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><h#></code> element in the Feed, or"
** 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code><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.

==== Feed author and Entry author (atom:author) ====
* {{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><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><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><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><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 id (atom:id) ====
* {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|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.
** --[[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].

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

* [[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 <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.
** [[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.

* [[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.
** [[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
***[[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.
****[[User:TobyInk]] - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
* [[User:Fil|Fil]] for the moment, to comply losely with hAtom 0.1, I will use <code><nowiki>My Name</nowiki></code> ; but it's not good
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki>My Name</nowiki></code>

==== Entry source (atom:source) ====
* raised by [[User:Kevin Marks|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.

== 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 ==
{{issues-format}}

== See Also ==
* [[hatom|hAtom]] - the draft proposal
* [[hatom-faq]] - knowledge base
* [[hatom-issues-resolved]]
* [[blog-post-brainstorming]]
* [[blog-post-formats]]
* [[blog-post-examples]]
* [[blog-description-format]] - how to describe a blog (as opposed to the individual entries, which is what we're doing here)
* [[mfo-examples]]
* [[naming-principles]]

Template:ToDo

2009-07-18T11:59:09Z

DavidJanes: New page: to do!

to do!

comment-brainstorming

2008-11-24T12:59:48Z

DavidJanes: /* if hAtom Entry is used, the Entry Title if not present should be */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 95% (note the usual DL/DT issues in some Blogger templates)
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** 0 [[User:DavidJanes|David Janes]] although it covers 100% of the examples, hAtom does have the concept of a cluster of related Entries, and thus I feel it would be better modeled that way.

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" (or similar) to a element around all comments ==

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]
** -1 [[User:DavidJanes|David Janes]]. Twitter has nothing in common with the other comments system listed. In particular, all replies on Twitter are first class "posts" on your own twitter stream, are done in your own user context, and may not even be replies as they may be conversation initiations.

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ''X'' ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]
** [[User:DavidJanes|David Janes]] I'm happy to have whatever made up by parser implementers, which seems to be the way Atom feeds happen today. I have issues with specing English words, as it's non-I18N friendly.

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:57:47Z

DavidJanes: /* Twitter is a comments system */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 95% (note the usual DL/DT issues in some Blogger templates)
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** 0 [[User:DavidJanes|David Janes]] although it covers 100% of the examples, hAtom does have the concept of a cluster of related Entries, and thus I feel it would be better modeled that way.

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" (or similar) to a element around all comments ==

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]
** -1 [[User:DavidJanes|David Janes]]. Twitter has nothing in common with the other comments system listed. In particular, all replies on Twitter are first class "posts" on your own twitter stream, are done in your own user context, and may not even be replies as they may be conversation initiations.

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:55:57Z

DavidJanes: /* add class="comment" to the comment Entry */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 95% (note the usual DL/DT issues in some Blogger templates)
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** 0 [[User:DavidJanes|David Janes]] although it covers 100% of the examples, hAtom does have the concept of a cluster of related Entries, and thus I feel it would be better modeled that way.

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" (or similar) to a element around all comments ==

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:53:23Z

DavidJanes: /* add class="comments" to a element around all comments */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 100%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" (or similar) to a element around all comments ==

* notes:
* test cases covered: 10)%
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]. I'm thinking of this as Entry Replies, which would be physically represented as whatever. Using Entry Replies around all comments would reflect the fact that in 100% of the examples comments come in bunches.

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:43:15Z

DavidJanes: /* mark the comment permalink with rel="reply" */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have several objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed. I have doubt too about how well this will work if the document that's being replied to is specified with hashed URL.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 100%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:41:56Z

DavidJanes: /* add an independent rel="in-reply-to" link */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have two objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]
** [[User:DavidJanes|David Janes]] -1. This seems be inventing something that for the most part is already covered, i.e. is entirely an orthogonal solution. I do not deny this could be of great utility as part of a general threading microformat, but that would have to be independently analyzed.

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 100%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:39:29Z

DavidJanes: /* mark the comment permalink with rel="reply" */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** -0.5 [[User:DavidJanes|David Janes]] I have two objections: this seems to be a proper subset of what could be covered by marking a comment hEntry with class="comment", and it seems to being opening up a general "reply/threading" microformat that should be completely and independently analyzed.

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 100%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-24T12:37:44Z

DavidJanes: /* use hAtom Entry for a comment */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered: 95%
** the blogger comments marked as a definition list is problematic, as there is no object that wraps an entire comment
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]
** +1 [[User:TobyInk|TobyInk]]
** +1 [[User:DavidJanes|David Janes]]

== mark the comment permalink with rel="reply" ==

* notes:
** By adding "rel-reply" the author is indicating that the resource indicated by the href is a "reply" to the current document.
* test cases covered:
** 60%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:
** Who proposed this? Sounds like an an abuse of the meaning of <code>rel</code>. -1 from me. [[User:TobyInk|TobyInk]]

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:
** As long as it's ''optional'' (i.e. not the only way to mark that an hentry is a reply to something), my vote is +1. [[User:TobyInk|TobyInk]]

== add class="comment" to the comment Entry ==

* notes:
** All the examples studied were the concept of a comment
* test cases covered:
** 100%
* comments and votes:
** +1 [[User:WebOrganics|Martin McEvoy]]

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1 [[User:TobyInk|TobyInk]]

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:
** +1, but would prefer <code>class="replies"</code> because of analogy with Atom. Better to reuse an existing vocabulary than pull terms out of a hat. [[User:TobyInk|TobyInk]]

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:
** Indeedy. [[User:TobyInk|TobyInk]]

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:
** assuming that there is some kind of explicit, programmably-discoverable link between the comments and the thing being commented on (be it through nesting, an anchor link or some other method), then it is almost unavoidable that a comment microformat would be able to deal with hierarchical comments. After all, a hierarchical set of comments is merely a set of comments such that some of the comments are comments commenting on other comments. (I wonder if I could have avoided using the word "comment" six times in that previous sentence?) [[User:TobyInk|TobyInk]]
** +1 Yes As all comments that I have looked at DO have a hierarchical structure, some nested inside each other as replies to other comments. I believe in "most" cases [[xoxo]] (<nowiki><ol></nowiki> and <nowiki><ul></nowiki>) can address the problems of structure and hierarchy, this {{should}} however be totally optional, or maybe just a design note [[User:WebOrganics|Martin McEvoy]]

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:
** +1 Use the author value of the hentry presented in a contextual way, for example by prefixing the author value with "by" or appending it with "said" or "says" [[User:WebOrganics|Martin McEvoy]]

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-18T11:58:32Z

DavidJanes: Added a Entry Title section

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered:
* comments and votes:

== mark the comment permalink with rel="reply" ==

* notes:
* test cases covered:
* comments and votes:

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:

== add class="comment" to the comment Entry ==

* notes:
* test cases covered:
* comments and votes:

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:

== if hAtom Entry is used, the Entry Title if not present should be ==

* comments and votes:

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-18T11:57:21Z

DavidJanes: /* suggested usage template for above */

= Brainstorming for a Comment Microformat =
{{TOC-right}}

This is a brainstorm for comment microformat. Examples of a comment can be found here [[comment-examples]]

== Problem ==

Shortform: How do you track blog comments you've made?

Longform: How do track the comments you have made on blogs, comments made on blogs your interested in and comments other people have made on your own blog?

How can you do this in a pragmatic way, ingested into some kind of data store, searched or aggregated?

== Contributors ==
* [[User:Csarven|Sarven Capadisli]]
* [[User:Singpolyma|Singpolyma]]
* [[User:WebOrganics|Martin McEvoy]]
* [[User:DavidJanes|David Janes]]
* [[User:TobyInk|TobyInk]]

== Discovered Elements ==

Based on the analysis of 25 real world examples of a comment, the results can be found at the [[comment-examples#Analysis| Comment Analysis]] section

The following properties occur most regularly across all examples (84% or more)

* comment 100%
* author 96%
* published 96%
* author-url 84%

'''Other achievable elements'''

* comment-link (permalink) 60%

== Schema I ==

===Proposal===

* '''hentry''' (root class name)
** The <code>hentry</code> element represents an individual entry for a comment.
**# http://microformats.org/wiki/hatom#Entry

* '''author''' (author) 96%
** an Entry Author element {{must}} be encoded in a [[hcard|hCard]]
**# http://microformats.org/wiki/hatom#Entry_Author

* '''url''' (author-url) 84%
** Use the url value of a [[hcard]]

* '''entry-content''' (comment) 100%
** The "logical Entry Content" of an Entry is the concatenation, in order of appearance, of all the Entry Contents within the Entry
**# http://microformats.org/wiki/hatom#Entry_Content

* '''updated''' (date) 96%
** use the [[datetime-design-pattern]] to encode the updated datetime
**# http://microformats.org/wiki/hatom#Entry_Updated

* '''reply''' (comment-link) 60%
** By adding "rel-reply" the author is indicating that the page <nowiki>http://someblog/post#comment-001</nowiki> is a reply for the referring page (see example).
**# <code>reply</code> {{may}} be defined as rfc4685 section 3 ([http://tools.ietf.org/html/rfc4685#section-3 1]) in-reply-to [http://tools.ietf.org/html/rfc4685 atom threading extension].
**# A parser {{may}} use the referring page <nowiki>http://someblog/post</nowiki> as the value of in-reply-to (see transformation)

==== Example ====

<pre>
<div class="hentry" id="comment-001">

<a class="url fn" href="http://contributor.com/blog/">Author</a> said

about 72 days ago,
<div class="entry-content">
Hey Great Post
</div>
<a rel="reply bookmark" href="http://someblog/post#comment-001">link to this</a>
</div>
</pre>

==== Transformation ====

<pre>
<entry>
<id>http://someblog/post#comment-001</id>
<title>Author said</title>
<updated>2008-09-01T14:40:45+01:00</updated>
<author>
<name>Author</name>
<uri>http://contributor.com/blog/</uri>
</author>
<link rel="alternate" href="http://someblog/post#comment-001" type="text/html"/>
<thr:in-reply-to
ref="http://someblog/post"
type="text/html"
href="http://someblog/post"/>
<content>Hey Great Post</content>
</entry>
</pre>

===Parser Notes===

* If the <code>entry-title</code> element is not used, the atom:title element {{should}} use the <code>author</code> value of the <code>hentry</code> presented in a contextual way, for example by prefixing the <code>author</code> value with "by" or appending it with "said" or "says".
* The <code>entry-title</code> element {{should}} provide [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#rfc.section.4.1.1.1 textual content] and not be an empty string.

===Summary===

* This proposal means that on the whole nothing much is needed for a [[comment]] microformat, a comment can re-use terms outlined in the [[hatom|hAtom Microformat]], but instead of using just [[rel-bookmark]] use [[rel-reply]] as well to indicate that the [[hatom#Entry| hEntry]] is also a reply.

===References===

* [[comment-formats#Atom_Threading_Extension|Comment Formats]]
* [[hatom|hAtom Microformat]]
* Atom Threading Extensions [http://tools.ietf.org/html/rfc4685 rfc4685]

===Design Notes===
* [http://www.w3.org/DesignIssues/LinkedData.html Linked Data] (Tim Berners-Lee 2006)
* [http://en.wikipedia.org/wiki/Dereferenceable_Uniform_Resource_Identifier Dereferenceable Uniform Resource Identifier] (Wikipedia)

== Schema II ==

===Proposal===

* reuse [[hAtom]]
* if Entry "B" is in an Entry Comments element of Entry "A", then Entry "B" is a comment on Entry "A"
* an Entry Comments element is identified by using both class names "hfeed comments"

<pre>
<div class="hentry">
<h3 class="entry-title">The blog post title</h3>
<div class="entry-content">The blog post text</div>
(etc)
<div class="hfeed comments">
<div class="hentry" id="p0001">
<div class="entry-content">Comment #1</div>
(etc)
</div>
<div class="hentry" id="p0002">
<div class="entry-content">Comment #2</div>
(etc)
</div>
</div>
</div>
</pre>

=== Details ===

* if there is no Entry Title for a comment <strike>it can be assumed to be empty</strike>, it can be invented by the parser
* this was discussed at [http://sgfoocamp08.pbwiki.com/ SGFooCamp], see: http://www.flickr.com/photos/90594399@N00/2271787498/

=== Specific Example from the Wild ===

hAtom Comments changes are marked IN UPPER CASE LETTERS FOR VISIBILITY. Assume them to be the normal case in otherwise

(section to be completed)

==Feedback==

If we can indicate that the hAtom entries are also comments, we could add an indicator beside hAtom.
<pre><nowiki>
<div class="hfeed hcomment">

hAtom pattern goes here.

</div>
</nowiki>
</pre>

Alternatively, we could add <code>hcomment</code> with <code>hentry</code> to indicate that the following hentry can be treated also as a comment.
<pre><nowiki>
<div class="hentry hcomment">

hEntry pattern goes here.

</div>
</nowiki></pre>
--[[User:Csarven|Sarven Capadisli]] 11:59, 25 Sep 2008 (PDT)

* If an hfeed is embedded in an hEntry, that could be enough context to show "these items are replies to the one they're embedded in" [[User:Singpolyma|singpolyma]] 12:20, 25 Sep 2008 (PDT)

== hAtom and in-reply-to ==

A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
<pre><nowiki>
<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>
</nowiki></pre>

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

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

By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

Example comment using in-reply-to: http://www.csarven.ca/my-responses-are-in-white

--[[User:Csarven|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

= Idea Consolidation =

This is a list of all the various "micro-ideas" that have been discussed on the mailing list in the Wiki, to capture everyone's thoughts and preferences.
* "examples covered" indicates the percentage of [[comment-examples|examples]] that can be marked up without presentation changes
* Add your comments, objections and votes (-1, 0, +1) as a sublist in "comments" with your wikiname.

== use hAtom Entry for a comment ==

* notes:
* test cases covered:
* comments and votes:

== mark the comment permalink with rel="reply" ==

* notes:
* test cases covered:
* comments and votes:

== mark the comment permalink with rel="in-reply-to" ==

* notes:
* test cases covered:
* comments and votes:

== add an independent rel="in-reply-to" link ==

* notes:
* test cases covered:
* comments and votes:

== add class="comment" to the comment Entry ==

* notes:
* test cases covered:
* comments and votes:

== add hAtom Entry Feed around all comments ==

* notes:
* test cases covered:
* comments and votes:

== add class="comments" to a element around all comments ==

* notes:
* test cases covered:
* comments and votes:

== use XOXO to mark up comments ==

* notes:
* test cases covered:
* comments and votes:

== Twitter is a comments system ==

* notes:
* comments and votes:

== A comment microformat should deal with hierarchically nested comments ==

* notes:
* comments and votes:

== ''suggested usage template for above'' ==

* notes
** bla bla bla
* test cases covered:
** 50%
* comments and votes:
** +1 this is a great idea - [[SomeUser]]
** -1 this doesn't even work in have the cases - [[SomebodyElse]]
*** you don't even know how to spell "half" - [[SomeUser]]

= See Also =

* [[comment-problem|comment problem]]
* [[comment-examples]]
* [[comment-formats]]
* [[comment-brainstorming]]
* [[comment-issues]]

Related:

* [[hAtom]]
* [[hatom-brainstorming#User_comment_entries|hAtom comment brainstorming]].

comment-brainstorming

2008-11-18T11:52:12Z

DavidJanes: Added Twitter section

comment-brainstorming

2008-11-18T11:49:56Z

DavidJanes: Add Idea Consildation section

comment-examples

2008-11-17T15:15:24Z

DavidJanes: Twitter is not a comments system

== Tools ==

=== WordPress ===
* http://wordpress.org

** comment_ID
** comment_author
** comment_author_IP
** comment_author_email
** comment_author_link
** comment_type
** comment_text
** comment_excerpt
** comment_date
** comment_time

=== pMachine ===
* http://pmachine.com

** body
** date
** name
** location
** url
** email
** profile_link
** member_total_comments

=== Expression Engine ===
* http://pmachine.com

** {author_id}
** {comment}
** {comment_id}
** {ip_address}
** {name}
** {permalink}
** {url}
** {url_or_email}

Expression Engine includes many additional comments templates tags. This list excludes the following tags: tags used to display user data (instant message handles, location, occupation, etc.), tags which are used for navigation within EE-based blogs or websites, tags which deal with comment presentation (alternating background colors between comments), and custom member tags (which are defined by individual sites.)

=== Drupal ===
* http://drupal.org

** $comment->new
** $comment->subject
** $comment->cid
** $comment->nid
** $comment->timestamp
** $submitted
** $comment
** $picture
** $content
** $links

==Real world Examples==

The following urls are examples of user/visitor comments primarily about media, but are all in the context of a blog post or article.

* http://ryanedit.blogspot.com/2006/01/light-water-music-2.html
** Information displayed: author, author-url, comment, permalink

* http://prototypen.com/blog/vjblog/archives/001318.html
** Information displayed: author, author-url, comment, published

* http://www.itsjerrytime.com/?p=89
** Information displayed: author, author-url, comment, published, permalink

* http://bottomunion.com/blog/?p=469
** Information displayed: author, author-url, comment, published, permalink

* http://www.rocketboom.com/rb_07_mar_26/comments/
** Information displayed: author, author-url, comment, published, comments-link
** This page does not contain any comments - just a link to another page which has comments on. This should probably not be included in the tally.
*** Updated example to one that works.

* http://www.chesslodge.com/2007/03/chess-video-lesson-2/
** Information displayed: author, author-url, comment, published, permalink

* http://stevegarfield.blogs.com/videoblog/2007/04/sxsw_all_togeth.html
** Information displayed: author, author-url, comment, published, permalink

* http://blog.blip.tv/blog/2008/09/12/bliptv-the-new-york-television-festival/
** Information displayed: author, author-url, comment, published
** Nobody has commented on this page. This should probably not be included in the tally.
*** Changed url to one that works

* http://uk.youtube.com/watch?v=KKTDRqQtPO8
** Information displayed: author, author-url, comment, published, reply-url, vote, junk-report-link, inset-threaded-replies, pagination-links

* http://vimeo.com/162754
** Information displayed: author, author-url, comment, published, inset-threaded-replies

* http://www.dailymotion.com/commented-week/lang/en/video/x7a2my_lewis-hamilton-champion-f1-2008_sport
** Information displayed: author, author-url, comment, published, author-image, pagination-links

* http://www.nbc.com/Saturday_Night_Live/video/clips/mccain-qvc-open/805381/
** Information displayed: author, author-url, author-image, comment, published, junk-report-link

* http://www.accidenthash.com/2007/04/02/gray-wet-yuck-monday/
** Information displayed: author, author-url, comment, published, permalink

* http://freakytrigger.co.uk/ft/2008/11/blondie-call-me/
** Information displayed: author, author-url, comment, published, permalink, pagination-links

* http://www.scissorkick.com/2008/09/midnight-lab-band/
** Information displayed: author, author-image, comment, published, permalink

* http://www.arjanwrites.com/arjanwrites/2008/10/free-download-j.html#comments
** Information displayed: author, author-url, comment, published

* http://loki23.blogspot.com/2008/09/flower-electronics.html#comments
** Information displayed: author, author-url, comment, published, permalink

* http://videogum.com/archives/the-hunt-for-the-worst-movie-of-all-time/the-hunt-for-the-worst-movie-o-30_032141.html
** Information displayed: author, author-url, author-image, comment, published, permalink, vote, reply-url, inset-threaded-replies, in-reply-to-link

* http://www.haloscan.com/comments/empirestatehuman/7424868678376349884/
** Information displayed: author, author-url, comment, published, permalink, reply-link

* http://www.3hive.com/2008/10/1000_robata.php#comments
** Information displayed: author, author-url, comment, published, reply-link, inset-threaded-replies

* http://www.musicload.de/album/1884260_2/nik-p--dj-%C3%B6tzi/ein-stern-der-deinen-namen-tr%C3%A4gt/item.html
** Information displayed: author, comment, published, rating

* http://strongwordsinc.com/2007/05/31/episode-20-tranforming-you-into-stds-since-1983/#comments
** Information displayed: author, author-url, comment, published, permalink

* http://ackegard.com/gallery/v/campaigns/calipolis/LK03_Kyri_climbs.jpg.html?g2_imageViewsIndex=1
** Information displayed: author, comment, published

* http://www.elfwood.com/art/n/e/nelson/pixy.jpg.html#addnewcmt
** Information displayed: author, author-url, comment, published, pagination-links

* http://www.reddit.com/r/offbeat/comments/7d8k8/man_kills_whole_beehive_by_accident_pic/c06citf
** Information displayed: author, author-url, comment, published, permalink, reply-link, in-reply-to-link, inset-threaded-replies, vote

* http://slashdot.org/comments.pl?sid=1030805
** Information displayed: author, author-url, comment, published, permalink, reply-link, in-reply-to-link, inset-threaded-replies, title, vote, pagination-links

* http://twitter.com/t
** Information displayed: comment, software-used, published, permalink, in-reply-to-link, pagination-links
** [[DavidJanes]]: this is not an example of a comments system

=== Analysis ===

25 examples

* comment 100%
* author 96%
* published 96%
* author-url 84%
* permalink 60%
* pagination-links 24%
* inset-threaded-replies 20%
* author-image 16%
* in-reply-to-link 16%
* reply-link 16%
* vote 16%
* junk-report-link 8%
* reply-url 8%
* rating 4%
* software-used 4%
* title 4%

=== Selected Examples ===

==== Blogspot #1 ====

* http://ryanedit.blogspot.com/2006/01/light-water-music-2.html
* issue: DL lists only allow DT/DD children; how do we do hAtom?
** The first step in realising the solution is to create a separate <code><dl></code> element for each individual comment.
*** The next step is to realise that these elements have been chosen poorly to being with. Each of the wrapping <code><dl></code> elements should be <code><div></code>s; the <code><dt></code> elements should probably be <code><address></code>; the comments themselves perhaps <code><blockquote></code> and the footers <code><div></code>.

<pre>
<dl id='comments-block'>

<dt class='comment-author blogger-comment-icon' id='c113756252571588387'>
<a name='c113756252571588387'></a>
<a href='...' rel='nofollow'>french/new/wave/nerd</a> said...
</dt>
<dd class='comment-body'>
that was tasty. -taxiplasm
</dd>
<dd class='comment-footer'>

<a href='...' title='comment permalink'>9:35 PM</a>

</dd>


<dt class='comment-author blogger-comment-icon' id='c113756977236111956'>
<a name='c113756977236111956'></a>
<a href='...' rel='nofollow'>JuanFalla</a> said...
</dt> <dd class='comment-body'>
I wish i had your music ability. nice...
</dd>
<dd class='comment-footer'>

<a href='...' title='comment permalink'>11:36 PM</a>

</dd>
</dl>

</pre>

==== MovableType #1 ====

* http://prototypen.com/blog/vjblog/archives/001318.html

<pre>
<div class="comments-head">
<a name="comments"></a>
Comments
</div>
<div class="comments-body">
Is it right that this video ....
Thanks.

Posted by: <a href="...">Marco Bakera</a>
at November 8, 2005 08:34 AM

</div>
<div class="comments-body">
In the right column you find the ....
Attribution Noncommercial Share Alike...

Posted by: <a href="...">fALk</a>
at November 30, 2005 12:12 PM

</div>
</pre>

==== Wordpress #1 ====

* http://www.itsjerrytime.com/?p=89

<pre>
<h3 id="comments">
67 Responses to “THE TEXAS CHAINSAW CUSTOMER”
</h3>
<ol class="commentlist">

<li class="alt" id="comment-3779">
<cite>a fan</cite> Says:
 

<a href="#comment-3779" title="">October 17th, 2006 at 7:42 pm</a>

Sounds like a it’ll be good... 
</li>


<li class="" id="comment-3979">
<cite><a href='...' rel='external nofollow'>chase</a></cite> Says:
 

<a href="#comment-3979" title="">October 21st, 2006 at 5:25 pm</a>

hurry, hurry, hurry …
</li>
</ol>
</pre>

==== Video site #1 ====

* http://vimeo.com/162754

<pre>
<ul class="comments" id="comments_162754">

<li class="parent first">
<a name="comment_120581"></a>
<img src="..." alt="" class="portrait" />
<div class="rightside">
<div class="name">
<a href="/videowombat">FuzzyDave</a>
2 years ago
</div>
<div class="text">
Another great short...
</div>
<div class="clear"></div>
</li>


<li class="reply">
<a name="comment_120724"></a>
<img src="..." alt="" class="portrait" />
<div class="rightside">
<div class="name">
<a href="/joshflowers">JoshFlowers</a>
2 years ago
</div>
<div class="text">
Odd, I just suggested ...
</div>
</div>
<div class="clear"></div>
</li>
</ul>

</pre>

==== Video site #2 ====

* http://www.nbc.com/Saturday_Night_Live/video/clips/mccain-qvc-open/805381/
* this site loads comments by AJAX