- Should we talk about parsing of <time> element?. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it.
- Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. TobyInk 23:00, 21 March 2010 (UTC)
hatom-issues: Difference between revisions
m (Replace <entry-title> with {{DISPLAYTITLE:}}) |
|||
(172 intermediate revisions by 31 users not shown) | |||
Line 1: | Line 1: | ||
{{DISPLAYTITLE: hAtom issues }} | |||
These are externally raised issues about [[hAtom]] with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec. | |||
'''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 == | |||
<span id="Issues">Please add new issues</span> to the '''bottom''' of the list by copy and pasting the [[#Template|Template]]. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted. | |||
=== | ===2010=== | ||
==== No defined parsing rule for <code>updated</code> timestamps in <code>ins</code>elements ==== | |||
* {{OpenIssue}} 2010-01-20 raised by [[User:BenWard|BenWard]] | |||
*# hAtom includes the <code>updated</code> property for the last modification/revision date of an entry. HTML already has an <code>ins</code> element for marking up inserted changes to text, and that element has a <code>datetime</code> attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from that <code>datetime</code> attribute, but the document semantics suggest it would be an appropriate source for the <code>updated</code> property. Example: <http://blog.benward.me/post/250674456> | |||
*#* Proposed resolution. Document a parsing rule for the <code>ins</code> element, stating that for an <code>ins</code> (or <code>del</code>) element with class of <code>updated</code>, the value of the <code>datetime</code> attribute should be used as the value. | |||
*#** +1 This sounds like a good idea and something worthy of being incorporated into [[hcard-parsing#more_semantic_exceptions]] (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC) | |||
*#* This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC) | |||
*#* Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where <code>update</code> is not explicitly marked up, the parser may aggregate all <code>ins</code> and <code>del</code> elements in the <code>hentry</code>, and use the most recent <code>datetime</code> attribute content as the <code>updated</code> value. | |||
*#** +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. [[User:Tantek|Tantek]] 17:43, 21 January 2010 (UTC) | |||
< | <div class="hentry"> | ||
{{OpenIssue}} | |||
<span class="entry-summary author vcard"> | |||
<span class="published">2010-03-20</span> | |||
raised by <span class="fn">[[User:Singpolyma|Singpolyma]]</span> | |||
</span> | |||
<div class="entry-content discussion issues"> | |||
* <strong class="entry-title">Should we talk about parsing of <time> element?</strong>. I use this element to mark up published on my blog. It is not supported by any implementation that I know of. Should implementors be encouraged to add this? Should the spec talk about it as an alternative to datetime-design-pattern? That page currently says to check the hcal issues, but there is nothing there about it. | |||
** Swignition has supported this for well over a year. It's also been supported in HTML::Microformats since version 0.00_00. [[User:TobyInk|TobyInk]] 23:00, 21 March 2010 (UTC) | |||
</div> | |||
</div> | |||
* [[ | ===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) | ||
* [[User: | *#** entry:author should be optional and could be either a hCard or a string | ||
*#** entry lacks a [http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.category category] and it shuld either use rel-tag or just be a string | |||
* [[ | * 2009-07-18 [[User:DavidJanes]] I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules | ||
* 2009-07-21 [[User:TobyInk|TobyInk]]: Why not have three levels of property: ''required'', ''recommended'' and ''optional''. There would be as few as possible ''required'' properties. Any properties which are needed to create a conformant application/atom+xml feed would be ''recommended''. Everything else would be ''optional''.' | |||
** 2009-07-02 [[User:DavidJanes]] why not then use the RFC MUST, SHOULD and MAY terminology? I think this is a good idea though. | |||
** 2009-09-03 [[User:Chris Cressman|Chris Cressman]] +1 to the idea of property "levels" and reusing RFC terminology. | |||
=== | ==== entry-title optionality ==== | ||
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]] | |||
** this element should be optional | |||
*** +1 [[User:DavidJanes]] | |||
*** +1 [[User:WebOrganics|Martin McEvoy]] but not recommended. | |||
*** +1 [[User:Bmearns|Bmearns]] I think this format has much broader application without this limitation. I'm thinking, for instance, of the Facebook news feed, or a twitter feed, both of which could use this microformat but do not in general have titles for each post. | |||
*** ... your vote here ... | |||
** if this element is not in the [[hatom#In_General|physical model]], the logical model value should be | |||
*** the empty string | |||
**** +1 [[User:DavidJanes]] | |||
**** -1 [[User:WebOrganics|Martin McEvoy]] | |||
*** the value should not be blank. | |||
**** +1 [[User:WebOrganics|Martin McEvoy]] see: [http://www.atomenabled.org/developers/syndication/#requiredEntryElements Required Entry Elements] from Atom Enabled. | |||
**** [[User:DavidJanes]] what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string? | |||
***** [[User:WebOrganics|Martin McEvoy]] entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string. | |||
*** the value should be NULL. | |||
**** +1 [[User:Bmearns|Bmearns]]: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate <code><H1></H1></code>, as opposed to just omitting the title all together. | |||
*** ... your proposal here, your vote in a sublist ... | |||
* include in hAtom 0.2 | |||
** +1 [[User:DavidJanes]] | |||
** +1 [[User:WebOrganics|Martin McEvoy]] | |||
** +1 [[User:Bmearns|Bmearns]] | |||
==== updated optionality ==== | |||
* {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]] | |||
** this element should be optional | |||
*** +1 [[User:DavidJanes]] ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element | |||
*** +1 [[User:Chris Cressman|Chris Cressman]] Agree there is demand for optionality. This requirement has previously deterred me from using hAtom. | |||
** if this element is not in the [[hatom#In_General|physical model]], the logical model should be | |||
*** the page creation date | |||
**** +1 [[User:DavidJanes]] | |||
**** +1 [[User:Chris Cressman|Chris Cressman]] | |||
*** ... your proposal here, your vote in a sublist ... | |||
* include in hAtom 0.2 | |||
** +1 [[User:DavidJanes]] | |||
** +1 [[User:Chris Cressman|Chris Cressman]] | |||
==== author optionality ==== | |||
* | * {{OpenIssue}} 2009-07-18 raised by [[User:DavidJanes]] | ||
* | ** this element should be optional | ||
** +1 DavidJanes | *** +1 [[User:DavidJanes]] for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise | ||
** +1 | *** +1 [[User:Chris Cressman|Chris Cressman]] Same reason as 'updated' above. | ||
** + | *** ... your vote here ... | ||
** +1 | ** if this element is not in the [[hatom#In_General|physical model]], the logical model should be | ||
** +1 | *** "anonymous" (somewhat like [[hreview]]), except not explicit | ||
**** +0.5 [[User:DavidJanes]] | |||
**** 0 [[User:Chris Cressman|Chris Cressman]] Using a blog post as an example, I can determine the author from surrounding context. 'Anonymous' doesn't seem like an acceptable solution. However, I don't have the technical expertise to create a better solution and would be willing to accept 'anonymous'. | |||
*** make this implementation defined | |||
*** something constructed from the page's URL & other information | |||
*** ... your proposal here, your vote in a sublist ... | |||
* include in hAtom 0.2 | |||
** +1 [[User:DavidJanes]] | |||
** +1 [[User:Chris Cressman|Chris Cressman]] | |||
==== | === 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]] | |||
*#** +1 [[User:Chris Cressman|Chris Cressman]] Prefer microformat solutions that don't dictate specific elements. | |||
* include in hAtom 0.2 | |||
** +1 [[User:DavidJanes]] | |||
** +1 [[User:Chris Cressman|Chris Cressman]] | |||
== | === 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? | |||
** +1 [[User:Chris Cressman|Chris Cressman]] | |||
* include in hAtom 0.2 | |||
** +1 [[User:DavidJanes]] | |||
** +1 [[User:Chris Cressman|Chris Cressman]] | |||
==== 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. | |||
The | |||
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:<i>updated</i> and atom:<i>published</i>) ==== | ||
* 2006-05-23 raised by [[User:RobertBachmann|Robert Bachmann]] | |||
** Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used. | |||
*** ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use | |||
** 2009-07-20 [[User:DavidJanes]] {{ToDo}} is this moot? can we move this to resolved? | |||
=== | ==== Feed <i>id</i> (atom:<i>id</i>) ==== | ||
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]] | |||
*# atom:<i>id</i> is required for atom: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 | |||
** -1 | |||
=== | ==== Feed <i>permalink</i> (atom:<i>permalink</i>) ==== | ||
* [[ | * {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]]</small> | ||
* | ** 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. | ||
* [[DavidJanes]]: | ** 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 <i>updated</i> (atom:<i>updated</i>) ==== | ||
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]] | |||
** atom:<i>updated</i> 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]] | |||
** +0.5 [[ | |||
==== Feed <i>title</i> (atom:<i>title</i>) ==== | |||
* {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]] | |||
** atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules: | |||
**# a Feed Title element is identified by the class name <code><del>entry</del><ins>feed</ins>-title</code> | |||
**# a Feed SHOULD have an Feed Title | |||
**# a Feed Title element represents the concept of an Atom feed title | |||
**# if the Feed Title is missing, use | |||
**#* <del>the first <code><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 <i>author</i> and Entry author (atom:<i>author</i>) ==== | ||
* [[ | * {{OpenIssue}} 2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]] | ||
* [[ | ** I'm proposing the following rules for Feed author: | ||
**# a Feed Author element is represented by class name <code>author</code> at the feed level (inside a Feed element but not inside an Entry element) | |||
* [[ | **# a Feed Author element represents the concept of a Atom author | ||
* [[ | **# a Feed Author element MUST be encoded in a [[hcard|hCard]] | ||
* [[ | **# a Feed Author element SHOULD be encoded in a <code><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 | ==== Entry <i>id</i> (atom:<i>id</i>) ==== | ||
The | * {{OpenIssue}}2006-04-01 raised by [[User:RobertBachmann|Robert Bachmann]] | ||
** atom:<i>id</i> is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id. | |||
** --[[User:Federico|Federico]] 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry. | |||
** 2006-12-31 response by [[User:ComputerKid|Emanla Eraton]] No, it shouldn't be a permalink. It should be a "tag:" id for entries. | |||
** 2007-06-06 [[RyanKing]] - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [http://www.w3.org/TR/html401/types.html#type-name], while tag URIs require them [http://www.faqs.org/rfcs/rfc4151.html]. | |||
==== 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><span class="author"><span class="vcard"><span class="fn">My Name</span></span></span></nowiki></code> ; but it's not good | |||
** [[Tantek]] You can actually simplify that (one fewer span) with: <code><nowiki><span class="author vcard"><span class="fn">My Name</span></span></nowiki></code> | |||
* require author as [[hCard]] (i.e. no change from 0.1) | |||
** +2 [[User:DavidJanes]] | |||
==== Entry <i>source</i> (atom:<i>source</i>) ==== | |||
* | * 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 | === 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 == | == See Also == | ||
* [[hatom|hAtom]] - the draft proposal | * [[hatom|hAtom]] - the draft proposal | ||
* [[hatom-faq]] - knowledge base | * [[hatom-faq]] - knowledge base | ||
* [[hatom-issues-resolved]] | |||
* [[blog-post-brainstorming]] | * [[blog-post-brainstorming]] | ||
* [[blog-post-formats]] | * [[blog-post-formats]] | ||
Line 440: | Line 310: | ||
* [[mfo-examples]] | * [[mfo-examples]] | ||
* [[naming-principles]] | * [[naming-principles]] | ||
Latest revision as of 16:23, 18 July 2020
These are externally raised issues about hAtom with broadly varying degrees of merit. Thus some issues are REJECTED for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be ACCEPTED and perhaps cause changes or improved explanations in the spec.
IMPORTANT: Please read the hAtom FAQ and the hAtom resolved issues before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.
Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well. — Tantek
closed issues
See: hatom-issues-closed
resolved issues
issues
Please add new issues to the bottom of the list by copy and pasting the Template. Please follow-up to resolved/rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.
2010
No defined parsing rule for updated
timestamps in ins
elements
- open issue! 2010-01-20 raised by BenWard
- hAtom includes the
updated
property for the last modification/revision date of an entry. HTML already has anins
element for marking up inserted changes to text, and that element has adatetime
attribute, to document the date and time of the change. Currently, hAtom and microformats have no model for parsing the data from thatdatetime
attribute, but the document semantics suggest it would be an appropriate source for theupdated
property. Example: <http://blog.benward.me/post/250674456>- Proposed resolution. Document a parsing rule for the
ins
element, stating that for anins
(ordel
) element with class ofupdated
, the value of thedatetime
attribute should be used as the value.- +1 This sounds like a good idea and something worthy of being incorporated into hcard-parsing#more_semantic_exceptions (which is where the core of generic microformat parsing is currently documented) for special handling for all datetime properties. Tantek 17:43, 21 January 2010 (UTC)
- This has been supported by Swignition for well over a year, and is supported by HTML::Microformats. TobyInk 23:00, 21 March 2010 (UTC)
- Proposed extended resolution: As well as the above explicit parsing rule, an implication parsing rule stating that where
update
is not explicitly marked up, the parser may aggregate allins
anddel
elements in thehentry
, and use the most recentdatetime
attribute content as theupdated
value.- +1 Brilliant. Indeed right now 'updated', if missing, is implied from the 'published' property. Suggested change to that rule (incorporating your proposal) : if 'updated' is missing, use the latest in time value of: the 'published' property value, and the 'datetime' attributes of all ins and del elements inside the hentry. Tantek 17:43, 21 January 2010 (UTC)
- Proposed resolution. Document a parsing rule for the
- hAtom includes the
open issue!
2009
too many required hentry properties
- open issue! 2009-05-26 raised by 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 is required, and not always available).
- Proposed resolution. Make nearly all hentry properties "optional" in hAtom 0.2. Consider keeping at most only one required property, perhaps "updated" - that is, if there is no date of update/publication in the content you are trying to mark up, then perhaps it doesn't make sense to mark up that content with hAtom, since hAtom is for episodic, time-based/stamped content.
- consider pattern abstraction: all microformats should minimize "required" properties for the same reason, and perhaps only require at most a single property which is indicative of what that microformat is for, that is, if the author does not publish that one required property, then perhaps they should not be using the microformat that requires that one property.
- I have the same problem. I'm collecting various feeds to analyse them. The sources are often RSS 0.9, but I want to put the results into an Atom feed. --Simon Brodtmann 00:51, 1 July 2009 (UTC)
- entry:author should be optional and could be either a hCard or a string
- entry lacks a category and it shuld either use rel-tag or just be a string
- 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.
- hAtom 0.1 requires numerous properties for an hentry (often based directly on required elements from the Atom standard). Given the broad variety of situations that hAtom is used in content, many (or even most) of these properties are not already specified in such content, and thus it is poor methodology to require them because there is a good chance (experience has shown) either (a) the content author will ignore the requirement, or (b) will make something up to satisfy the requirement. A few similar/overlapping/sub-issues are noted below (e.g. author is required, and not always available).
- 2009-07-18 User:DavidJanes I would like to break this into a separate issue for each currently required element, as we're likely to have to define defaulting rules
- 2009-07-21 TobyInk: Why not have three levels of property: required, recommended and optional. There would be as few as possible required properties. Any properties which are needed to create a conformant application/atom+xml feed would be recommended. Everything else would be optional.'
- 2009-07-02 User:DavidJanes why not then use the RFC MUST, SHOULD and MAY terminology? I think this is a good idea though.
- 2009-09-03 Chris Cressman +1 to the idea of property "levels" and reusing RFC terminology.
entry-title optionality
- open issue! 2009-07-18 raised by User:DavidJanes
- this element should be optional
- +1 User:DavidJanes
- +1 Martin McEvoy but not recommended.
- +1 Bmearns I think this format has much broader application without this limitation. I'm thinking, for instance, of the Facebook news feed, or a twitter feed, both of which could use this microformat but do not in general have titles for each post.
- ... your vote here ...
- if this element is not in the physical model, the logical model value should be
- the empty string
- +1 User:DavidJanes
- -1 Martin McEvoy
- the value should not be blank.
- +1 Martin McEvoy see: Required Entry Elements from Atom Enabled.
- User:DavidJanes what should it be then, if physically representing it is optional? Since Atom makes this a SHOULD and not a MUST (I'm not shouting, just following RFC convention), and we're assuming there's a good reason for the entry-title not to be present in the first place, why not an empty string?
- Martin McEvoy entry:title is a required attribute of atom at both feed and entry level, in both instances it says "Contains a human readable title" (a requirement) an empty string is not anything human readable (personal oppinion), maybe hAtom 0.2 should only recommend that the value of entry-title "should" not be an empty string.
- the value should be NULL.
- +1 Bmearns: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate
<H1></H1>
, as opposed to just omitting the title all together.
- +1 Bmearns: Whatever that may mean to the specific handler. A blank string implies that a handler which generates HTML content, for instance, should generate
- ... your proposal here, your vote in a sublist ...
- the empty string
- this element should be optional
- include in hAtom 0.2
- +1 User:DavidJanes
- +1 Martin McEvoy
- +1 Bmearns
updated optionality
- open issue! 2009-07-18 raised by User:DavidJanes
- this element should be optional
- +1 User:DavidJanes ... the demand for optionality of the issue is high (cf the microsoft web clips) and if it remains required we're just going to reinvent hAtom without this element
- +1 Chris Cressman Agree there is demand for optionality. This requirement has previously deterred me from using hAtom.
- if this element is not in the physical model, the logical model should be
- the page creation date
- ... your proposal here, your vote in a sublist ...
- this element should be optional
- include in hAtom 0.2
author optionality
- open issue! 2009-07-18 raised by User:DavidJanes
- this element should be optional
- +1 User:DavidJanes for the same reason 'updated' should be optional: we'll just reinvent hAtom slightly differently otherwise
- +1 Chris Cressman Same reason as 'updated' above.
- ... your vote here ...
- if this element is not in the physical model, the logical model should be
- "anonymous" (somewhat like hreview), except not explicit
- +0.5 User:DavidJanes
- 0 Chris Cressman Using a blog post as an example, I can determine the author from surrounding context. 'Anonymous' doesn't seem like an acceptable solution. However, I don't have the technical expertise to create a better solution and would be willing to accept 'anonymous'.
- make this implementation defined
- something constructed from the page's URL & other information
- ... your proposal here, your vote in a sublist ...
- "anonymous" (somewhat like hreview), except not explicit
- this element should be optional
- include in hAtom 0.2
2008
add url property to hentry
- open issue! 2008-09-10 raised by Tantek
- hAtom 0.1 uses rel-bookmark for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the
url
property (from hCard, hCalendar, hReview, etc.) as a sub-property of thehentry
property/container/root.- Proposed resolution. Add "url" sub-property to "hentry" in hAtom 0.2.
- to do! can anyone provide examples where this would be used? User:DavidJanes
- hAtom 0.1 uses rel-bookmark for permalinks. Permalinks may not always be hyperlinks or hyperlinkable. Thus I propose we re-use the
misuse of address element
- open issue! 2008-06-07 raised by Tantek
- hAtom 0.1 says "an Entry Author element SHOULD be encoded in an
<address>
element" and "find the Nearest In Parent<address>
element(s) with class name author and that is/are a valid hCard" - this is a misuse of the address element. The address element means the contact for the page or major portion thereof (see hCard FAQ: Should I use ADDRESS for hCards), which may also be the author but is not necessarily. See hcards-and-pages for more details on this semantic distinction.- Proposed resolution: Eliminate all requirements and recommended use of the
<address>
element from hAtom.- +1 --Sarven Capadisli 11:57, 11 Nov 2008 (PST)
- +1 User:DavidJanes
- +1 Chris Cressman Prefer microformat solutions that don't dictate specific elements.
- Proposed resolution: Eliminate all requirements and recommended use of the
- hAtom 0.1 says "an Entry Author element SHOULD be encoded in an
- include in hAtom 0.2
2007
marking up comments
- open issue! 2007-11-25 raised by 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 4864. The microformat solution should map fairly cleanly to this.
- There's no currently defined way to exactly handle threaded discussions. I think this is quite useful to have.
- include in hAtom 0.2
- -1 User:DavidJanes I think hAtom Comments should be a separate spec
- +1 to David's -1. TobyInk They're in a separate RFC, so should be separate to hAtom too. That said, it would be nice if hAtom had a clear, documented mechanism for creating extensions.
- +1 Singpolyma Comments are the important "next step" for hAtom. The proposal I've seen that I most liked was embedding an hfeed in an hentry.
- User:DavidJanes would you look to explicitly write out that proposal here (or in a new section); this is my preferred solution too, but there's another proposal on the table for doing this too
- -1 User:DavidJanes I think hAtom Comments should be a separate spec
atom:category scheme
- open issue! 2007-06-01 raised by 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
- to do! can we get a real-world example mapping of this? User:DavidJanes
- rel-tag tagspaces should map to atom:category schemes
2006
Geo
- open issue! 2006-02-03 raised by BrianSuda
- We can use the geo microformat in hatom to represent GeoRSS element
- +1 User:DavidJanes - this is just making explicit a particular composition. is it not? Also: if there's a geo in a hfeed (outside of hentry), should it be considered to apply to all entries?
- +1 Chris Cressman
- include in hAtom 0.2
Relationship of rel-bookmark to url+uid
The concept of permalink is available in hCard and hCalendar as the classes url and uid. This combination matches the permalink semantics by indicating that the url should be derefenced to find a more dynamic or up-to-date version of the content, and that that url is a stable unique id that can be used to identify the content.
hAtom 0.1 uses rel-bookmark for the permalink concept. The current state of uid-brainstorming indicates that the hCard and hCalendar permalink concept is likely to be used in subsequent microformats. It may be important to reconcile hAtom with that trajectory. Possible reconcilliations include:
1) To leave things as they are. The two permalink concepts are to be kept separate.
2) Treat the two concepts as equivalent. Allow both in hAtom, and consider allowing both in other formats. eg <a rel="bookmark" href="http://example.com/"> would fill out uid and url values if they are not supplied explicitly.
3) Choose one over the other for hAtom and perhaps for future microformats also. "url uid" allows for some greater freedom (uid can be pointed at a non-url uid), but it is unclear at this stage whether that freedom is warranted or advisable to permit.
- include in hAtom 0.2
- -1 User:DavidJanes (let's wait for resolution elsewhere, also would need real world examples)
- -1 Singpolyma
Datetime format (atom:updated and atom:published)
- 2006-05-23 raised by Robert Bachmann
- Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
- ACCEPTED FAQ - hAtom references datetime-design-pattern, which discusses which date format to use
- 2009-07-20 User:DavidJanes to do! is this moot? can we move this to resolved?
- Atom requires the use RFC3339 datetimes, while hAtom 0.1 does not specify which datetime formats may be used.
Feed id (atom:id)
- open issue! 2006-04-01 raised by 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)
- open issue! 2006-04-01 raised by 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
SHOULDMAY 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 ChrisCasciano - I'm not sure that having a rel-boomkark-able link element at the feed level / to designate a feed in an html page separate for the other content is anything close to normal usage on the web, so I'd be very hesitant on suggesting this element "SHOULD" exist. I'm also curious when this element would link to anything but the current page (or some element on the current page) for this to be useful in the context of the HTML doc. I think taking the "id" on the feed is a more workable solution in most cases.
- 2006-04-03 Robert Bachmann: I've replaced "SHOULD" with "MAY".
- 2006-04-24 Robert Bachmann: Maybe we could simplify my proposal to:
- "Use the URI of the page; if the Feed has an "id" attribute, add that as a fragment to the page URI"
- IMO this would be good enough for at least 80% of the cases.
- 2006-04-12 User:DavidJanes: to do! can we find an example of this in the wild and if so we should add it to the -examples page.
- singpolyma 00:05, 13 Apr 2006 (PDT) : since the link is going to be pointing to the home page for the item wouldn't rel-home make more sense? That's what I'm using in the XOXO Blog Format and my reasoning was that if hAtom ever defined this rel=home made the most sense for what you would add, because the feed's link is not to a part of the site by to the home of the site.
- I'm proposing the following rules:
- include in hAtom 0.2
- -1 User:DavidJanes not enough development of these ideas yes
Feed updated (atom:updated)
- open issue! 2006-04-01 raised by Robert Bachmann
- atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
- The Feed Updated element is identified by the class name
updated
at the feed level (inside a Feed element but not inside an Entry element) - If no element with the class name
updated
is present, use the youngestupdated
from the feed's entries.
- The Feed Updated element is identified by the class name
- 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.
- atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
- include in hAtom 0.2
- +0.5 User:DavidJanes
Feed title (atom:title)
- open issue! 2006-04-01 raised by Robert Bachmann
- atom:title is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
- a Feed Title element is identified by the class name
entryfeed-title - 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
the first<h#>
element in the Feed, or- the
<title>
of the page, or - assume it is the empty string
- a Feed Title element is identified by the class name
- 2006-04-01 ChrisCasciano - I think that the fall back to using the first h# on the page is dangerous.. depending on the pge it may be something that changes often (first h# is a post title) or is otherwise ambiguous. I would think using
<title>
before h# would be prefered if not the most common desire of the page author. - 2006-04-05 Robert Bachmann: Okay. Deleted "the first
<h#>
element in the Feed, or" - 2006-04-12 User:DavidJanes Note also in support of this decision that many blogs use
<h#>
to encode the date for a group of postings - 2006-04-12 User:DavidJanes: why
entry-title
for the feed title. Why notfn
orfeed-title
? - 2006-04-12 Robert Bachmann: Sorry, this was a "copy & paste" mistake. Fixed now.
- 2007-02-26 Mike Kaply: I think a feed title should be mandatory if an hfeed is present. If you have multiple feeds on a page, there is no way in a user interface to distinguish between different feeds.
- atom:title is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:
Feed author and Entry author (atom:author)
- open issue! 2006-04-01 raised by Robert Bachmann
- I'm proposing the following rules for Feed author:
- a Feed Author element is represented by class name
author
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
- a Feed Author element SHOULD be encoded in a
<address>
element - a Feed MAY have more than one Feed Author elements
- if the Feed Author is missing
- find the Nearest In Parent
<address>
element(s) with class nameauthor
and that is/are a valid hCard - otherwise
the Feed is invalid hAtomthere is no Feed Author
- find the Nearest In Parent
- a Feed Author element is represented by class name
- I'm proposing the following rules for entry author:
- an Entry Author element is represented by class name
author
- an Entry Author element represents the concept of an Atom author
- an Entry Author element MUST be encoded in an hCard
- an Entry Author element SHOULD be encoded in an
<address>
element If a Feed has no Feed author each Entry MUST have at least one Entry Author element- If an Entry is enclosed by a Feed and this Feed has no Feed author, each Entry MUST have at least one Entry Author element. If an Entry is not enclosed by a Feed and has no Entry Author:
- find the Nearest In Parent
<address>
element(s) with class nameauthor
and that is/are a valid hCard - otherwise the Entry is invalid hAtom
- find the Nearest In Parent
- an Entry MAY have more than one Entry Author elements
- an Entry Author element is represented by class name
- singpolyma 00:11, 13 Apr 2006 (PDT) : feed should not be invalid hAtom if feed-level has no author -- it should be invalid if feed-level has no author AND one or more entries have no author. Also, one or more entries may be missing an author IF feed-level has an author.
- 2006-04-17 Robert Bachmann: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"
- I'm proposing the following rules for Feed author:
Entry id (atom:id)
- open issue!2006-04-01 raised by Robert Bachmann
- atom:id is required for atom:entry. Thus it should be available in hAtom to. The Entry permalink should be used as the entry id.
- --Federico 19:52, 25 Apr 2006 (PDT): I would add "Only if the id attribute is not defined for the element that contains the entry". The id attribute can be a tag uri. If you use always use the Entry permalink as the entry id and the Atom feed uses tag uris, you would end with two different ids for the same entry.
- 2006-12-31 response by Emanla Eraton No, it shouldn't be a permalink. It should be a "tag:" id for entries.
- 2007-06-06 RyanKing - the syntax of tag URIs and html id attributes are incompatible. HTML disallows forward-slash (/) in ids [1], while tag URIs require them [2].
Author
author as an hcard is too much to require
The following 3 items were extracted from the conversation starting on irc with logs available starting around here
- Fil If, for example, you are programming an "aggregator" of news syndicated from many sources like in Sedna, chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a <div class="author"> element.
- Tantek I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
- ChrisCasciano details of Fil's extraction in irc logs including sting data passed to his app in the form of "Béatrice XXXXXXX beatrice.xxxxxx@@zzzzzzzzz.com"
- Fil the example url was given up there (Sedna); note that the author information comes from syndication links; nobody is going to edit them to outline what is the name, what is the email and so on, as everything is flowing through automatically... so here the "author" data is dirty, and will not be cleaned into an hCard. We can force it to be in an hCard but it will be meaningless if the source (original data) wasn't built on an mf-enabled software.
- pnhChris i don't disagree.. the field often comes from places too dumb to follow these rules well; even cases like wordpress that allow users to present their name 1 of 6 or 8 difference ways (from username to LF, FN) .. its not just writing a template to output as hatom at that point... you have to go further upstream where the string to be displayed is chosen .. I also think its pointless to have 10 vcards on the same page whose only data is a generic name like "Chris"
- Tantek 10 vcards that are the same is pointless yes, but identifying who the author of 10 posts are is not pointless - that's the difference.
- ChrisCasciano Agreed, but I still have concerns that "author" in hAtom does not always make for good hCards, though the situations where it does is optimal. My comments in the conversation were old comments I've made before over concerns and hardships or the lack of desire to make crappy data more portable, in neither of these cases do I think my two comments alone provide reasons to make change from the hAtom 0.1 spec
- Frances - Just thought I'd mention a scenario I have where the author of an entry does make a pretty useless vCard - the author in each case is an entire team ("creative team", "technical department") etc., rather than a specific, identifiable, person. Some use may be regained when URL to specific team/information is included, in this circumstance.
- User:TobyInk - A vCard (thus an hCard) does not have to represent a person -- it could represent an organisation, or a department or team.
- 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.
- Fil for the moment, to comply losely with hAtom 0.1, I will use
<span class="author"><span class="vcard"><span class="fn">My Name</span></span></span>
; but it's not good- Tantek You can actually simplify that (one fewer span) with:
<span class="author vcard"><span class="fn">My Name</span></span>
- Tantek You can actually simplify that (one fewer span) with:
- require author as hCard (i.e. no change from 0.1)
Entry source (atom:source)
- raised by Kevin Marks
- When defining hAtom 0.1, atom:source was omitted. We should consider adding this back in as a useful element for providing citations of composite feeds.
- 2009-07-20 User:DavidJanes to do! we need an example of how this would look in the real world
- 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
Consider using this format (copy and paste this to the end of the list to add your issues; replace ~~~ with an external link if preferred) to report issues or feedback, so that issues can show up in hAtom subscriptions of this issues page. If open issues lack this markup, please add it.
Please post one issue per entry, to make them easier to manage. Avoid combining multiple issues into single reports, as this can confuse or muddle feedback, and puts a burden of separating the discrete issues onto someone else who 1. may not have the time, and 2. may not understand the issue in the same way as the original reporter.
<div class="hentry">
{{OpenIssue}}
<span class="entry-summary author vcard">
<span class="published">2011-MM-DD</span>
raised by <span class="fn">~~~</span>
</span>
<div class="entry-content discussion issues">
* <strong class="entry-title">«Short title of issue»</strong>. «Description of Issue»
** Follow-up comment #1
** Follow-up comment #2
</div>
</div>
See Also
- 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