hatom-issues-fr

(Difference between revisions)

Jump to: navigation, search
(Fixed broken links)
Current revision (23:22, 1 May 2007) (view source)
m (Reverted edit of Gazza, changed back to last version by ChristopheDucamp)
 
Line 56: Line 56:
-
* 2006-04-12 [[User:DavidJanes|DavidJanes]]: can we find an example of this in the wild and if so we should add it to the -examples page.
+
* 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.
* [[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.
Line 85: Line 85:
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element
<nowiki>*</nowiki> feed level = inside a Feed element but not inside an Entry element
-
* 2006-04-12 [[User:DavidJanes|DavidJanes]] I like this. And the definition of "feed level"
+
* 2006-04-12 [[User:DavidJanes]] I like this. And the definition of "feed level"
== Feed <i>title</i> (atom:<i>title</i>) ==
== Feed <i>title</i> (atom:<i>title</i>) ==
Line 105: Line 105:
:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code>&lt;h#></code> element in the Feed, or"
:: 2006-04-05 [[User:RobertBachmann|Robert Bachmann]]: Okay. Deleted "the first <code>&lt;h#></code> element in the Feed, or"
-
:: 2006-04-12 [[User:DavidJanes|DavidJanes]] Note also in support of this decision that many blogs use <code>&lt;h#></code> to encode the date for a group of postings
+
:: 2006-04-12 [[User:DavidJanes]] Note also in support of this decision that many blogs use <code>&lt;h#></code> to encode the date for a group of postings
-
* 2006-04-12 [[User:DavidJanes|DavidJanes]]: why <code>entry-title</code> for the feed title. Why not <code>fn</code> or <code>feed-title</code>?
+
* 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.
: 2006-04-12 [[User:RobertBachmann|Robert Bachmann]]: Sorry, this was a "copy & paste" mistake. Fixed now.
Line 168: Line 168:
* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.
* [[User:Fil|Fil]] If, for example, you are programming an "aggregator" of news syndicated from many sources like in [http://sedna.spip.org/sedna/ Sedna], chances are that you don't control what "authors" look like; they can be nicely microformated (if coming from an mf-enabled system), but most probably they will be internally represented by a string that contains, in some random order, a name, and/or an email, and so on. If you want to pass on this information in an hAtom feed, you can't possibly reformat it to an hCard. But you still want to pass it on in a &lt;div class="author"> element.
-
** [[User:Tantek|Tantek]] I don't believe the "can't possibly" statement.  Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.
+
** [[Tantek]] 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: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.
** [[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.
-
* [[User:pnhChris|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"
+
* [[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"
-
** [[User:Tantek|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.
+
** [[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: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: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: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
* [[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
-
** [[User:Tantek|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>
+
** [[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>
== Autres Questions et Problématiques ==
== Autres Questions et Problématiques ==
Line 187: Line 187:
The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom''  I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom?  -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)
The [[hatom-fr|hAtom]] 0.1 spec states ''if there is no Entry Updated element...the page is invalid hAtom''  I have a real problem with this because I work with [http://www.blogger.com/ Blogger], where we cannot output [[datetime-design-pattern]]-compatible datestrings for our posts... We can output some different human-readable formats and we can output a nanosecond unix-timestamp, but the template tags will not output YYYY-MM-DDTHH:MM:SS+ZZ:ZZ no matter what you do... so how are we to resolve this so that Blogger blogs can use hAtom?  -- [[User:Singpolyma|singpolyma]] 05:45, 28 Mar 2006 (PST)
-
* [[User:DavidJanes|DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.
+
* [[DavidJanes]]: I'm not sure if anything can be done. My thought right now is just to put "x-posted" (or whatever) as the semantic class name and eventually hope that they'll adopted something more flexible. A while back there was a proposal that ABBR be used to describe a parsable version of the date string (for example <code>title="day month-name year, hour12:minute ampm tz"</code>) but I think this is asking too much from creators and parsers.
** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats.  My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.
** [[User:Singpolyma|singpolyma]] 00:15, 13 Apr 2006 (PDT) : I am currently just adding the appropriate classes even though the contents are not valid date formats.  My parsers are more leniant anyway (using PHP's strtotime, so any format supported there will work), but that doesn't resolve the fact that my blogs ''cannot'' be parsed by other's hAtom parers as hAtom is now unless they too are so leniant.
Line 255: Line 255:
<code>atomfeed</code> (or rather, "atom-entry")
<code>atomfeed</code> (or rather, "atom-entry")
-
* [[User:DannyAyers|DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
+
* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
-
* [[User:DavidJanes|DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
+
* [[DavidJanes]]: It is possible, somewhat common, and [[blog-post-examples#Multiple_EntryGroups_on_a_page|documented]], that multiple feeds can appear on a single page, so it's insufficient to depend on the header, even though this may be the default case. You'll note that I've left out documenting a lot of concepts relating to feeds at a conceptual level, except for noting they exist because I think this is a bit of a swamp that's going to need more thinking
-
* [[User:DavidJanes|DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
+
* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
-
* [[User:DavidJanes|DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
+
* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
* [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT): This makes sense to me, the way vcalendar is optional since vevent is usually sufficient.
-
* [[User:Tantek|Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
+
* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
-
* [[User:DannyAyers|DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
+
* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --  
* [[User:DavidJanes|David Janes]] I'm thinking about it more -- I think so, just to split the content of the webpage up (as opposed to blogrolls, headers, footers, etc.) --  
-
* [[User:Tantek|Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
+
* [[Tantek]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
-
* [[User:Tantek|Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
+
* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:
** atom-feed
** atom-feed
** hfeed
** hfeed
Line 283: Line 283:
==== Discussion ====
==== Discussion ====
-
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[User:Tantek|Tantek]]
+
The feed is a root class name of hAtom, similar to "vcalendar" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]]. - [[Tantek]]
== Entry (atom:entry) ==
== Entry (atom:entry) ==
Line 293: Line 293:
<code>atomentry</code> (or rather, "atom-entry")
<code>atomentry</code> (or rather, "atom-entry")
-
* [[User:DannyAyers|DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
+
* [[DannyAyers]]: Why not simply "entry"? The parallel to Atom is clear, but in the context of a Web page, why add the reference? In case maybe you want to try for something approaching a string that won't get confused, my feeling is: forget it. Stick to the local semantics and let the doc-level (or HTML5 div level?) profile attribute disambiguate. Or to put it another way, it's premature to see a need at that point.
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
* I ([[User:DavidJanes|David Janes]]) chose the "atom" prefix:
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
** to disambiguate; it is just ''too'' likely that "entry" or "feed" would appear on a random webpage in some other context. My preference would be to have a declarative statement in the XHTML header which would render this argument moot, but at this point the community seems cool on the concept.
Line 299: Line 299:
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
** because Entrys will not be required to be in Feeds (these rules and the reasons where this can happen will be forthcoming), I choose to disambiguate both
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
*** I don't like the analogy; I think this is more useful than just Atom, so it should be made generic. [[User:DrErnie|Dr. Ernie]] 16:59, 25 Oct 2005 (PDT)
-
*** [[User:DannyAyers|DannyAyers]]:  My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
+
*** [[DannyAyers]]:  My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
-
***  [[User:Tantek|Tantek]]: This is actually difficult to consider outside the following issue.  In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
+
***  [[Tantek]]: This is actually difficult to consider outside the following issue.  In particular, if "entry" is to serve as a potential root class name (similar to "vevent", which may be a root of an [[hcalendar|hCalendar]] event, or may be present in the context of a "vcalendar"), then we should strongly consider "uniquifying" it per our root-class-name practices. Possibilities to consider:
**** atom-entry
**** atom-entry
**** hentry
**** hentry
Line 310: Line 310:
* <code>entry</code> (Atom consistency)
* <code>entry</code> (Atom consistency)
-
** +1 [[User:MarkRickerby|MarkRickerby]]
+
** +1 [[MarkRickerby]]
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>atom-entry</code> (Atom consistency with prefix)
* <code>hentry</code> (h* uF consistency)
* <code>hentry</code> (h* uF consistency)
-
** +1 [[User:DavidJanes|DavidJanes]]
+
** +1 [[DavidJanes]]
-
** +1 [[User:Tantek|Tantek]]
+
** +1 [[Tantek]]
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
+
** +1 [[BenjaminCarlyle]]
-
** +1 [[User:RyanKing|RyanKing]]
+
** +1 [[RyanKing]]
-
** +1 [[User:MarkRickerby|MarkRickerby]]
+
** +1 [[MarkRickerby]]
-
** +1 [[User:DannyAyers|DannyAyers]]
+
** +1 [[DannyAyers]]
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar|hCalendar]])
-
** -1 [[User:RyanKing|RyanKing]] - though its a standard, it doesn't have widespread adoption
+
** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption
==== Discussion ====
==== Discussion ====
-
* [[User:Tantek|Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in [[hcalendar|hCalendar]] (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal.  Thus I would be ok with excluding vjournal from [[hcalendar|hCalendar]], and pointing folks to use [[hatom|hAtom]] instead, even in the context of an [[hcalendar|hCalendar]] element that would otherwise be outputting vjournal entries.  To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and [[hatom|hAtom]] properties so that [[hatom|hAtom]] inside an [[hcalendar|hCalendar]] could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create [[hatom|hAtom]] via the journal feature of said tool.</p>
+
* [[Tantek]]: Since feed is optional in hAtom (thereby implying the context of the entire XHTML document as the feed), similar to how "vcalendar" is optional in hCalendar (thereby implying a vcalendar context for the entire document), the entry can also be a root class name, similar to "vevent" in [[hcalendar|hCalendar]], thus it should be fairly unique, per the root class name [[naming-principles]].</p><p>If we are deliberately rejecting "vjournal", then we may want to exclude the entire "vjournal" object (and any vjournal specific properties) from [[hcalendar|hCalendar]] so that we don't accidentally have two blog post microformats.([[RyanKing]] added this to [[hcalendar-issues]])</p><p>Having analyzed the list of vjournal properties and their semantics and compared them with the list of Atom elements and their semantics, I greatly prefer the list and semantics from Atom over vjournal.  Thus I would be ok with excluding vjournal from hCalendar, and pointing folks to use hAtom instead, even in the context of an hCalendar element that would otherwise be outputting vjournal entries.  To that extent, once hAtom has stabilized, we should develop a mapping between vjournal properties and hAtom properties so that hAtom inside an hCalendar could be converted into BEGIN:VJOURNAL...END:VJOURNAL objects in an iCalendar/ics stream, as well as allowing for the opposite, so that one could even use an iCalendar-compliant authoring tool to create hAtom via the journal feature of said tool.</p>
== Entrée Titre (atom:title) ==
== Entrée Titre (atom:title) ==
Line 334: Line 334:
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
* <code>summary</code>, as used by hReview, hCalendar, VJOURNAL
-
** [[User:Tantek|Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification.  We may want to avoid the use of 'summary' entirely within hAtom.
+
** [[Tantek]]: Though I agree with the reuse, in this context, it may be confusing for those reading/familiar-with the Atom specification.  We may want to avoid the use of 'summary' entirely within hAtom.
-
** -1 [[User:Kevin Marks|Kevin Marks]] (clashes with atom)
+
** -1 [[KevinMarks]] (clashes with atom)
* <code>Subject</code>, as used by SMTP email
* <code>Subject</code>, as used by SMTP email
** -1 [[RyanKing]] - different semantics, doesn't fit
** -1 [[RyanKing]] - different semantics, doesn't fit
Line 342: Line 342:
* <code>entry-title</code>
* <code>entry-title</code>
* <code>headline</code>
* <code>headline</code>
-
** +1 [[User:Tantek|Tantek]]
+
** +1 [[Tantek]]
-
** +1 [[User:Kevin Marks|Kevin Marks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
+
** +1 [[KevinMarks]], as this is what they are most like in blogposts [[User:Kevin Marks|Kevin Marks]]
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:entry/title only
+
** +1 [[BenjaminCarlyle]], atom:entry/title only
-
** +&frac12; [[User:DavidJanes|DavidJanes]], atom:entry/title only
+
** +&frac12; [[DavidJanes]], atom:entry/title only
-
** +&frac12; [[User:PaulBryson|PaulBryson]], redundant?
+
** +&frac12; [[PaulBryson]], redundant?
* <code>title</code> (Atom consistency)
* <code>title</code> (Atom consistency)
-
** -1 [[User:Tantek|Tantek]].  Already defined to mean something else in [[hcard|hCard]].  The same term should not be used to mean different things.
+
** -1 [[Tantek]].  Already defined to mean something else in [[hcard|hCard]].  The same term should not be used to mean different things.
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
* <code>entry-title</code> (Atom consistency, avoid hCard conflict)
-
** +&frac12; [[User:PaulBryson|PaulBryson]], clear=good / hyphenating=bad
+
** +&frac12; [[PaulBryson]], clear=good / hyphenating=bad
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
* <code>fn</code> (attempt to re-use from [[hcard|hCard]] and [[hreview|hReview]])
-
** &plusmn;0 [[User:DavidJanes|DavidJanes]] see my note below
+
** &plusmn;0 [[DavidJanes]] see my note below
-
** -1 [[User:Tantek|Tantek]] (does not mean the "name" of the post/entry)
+
** -1 [[Tantek]] (does not mean the "name" of the post/entry)
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]], atom:feed/title only
+
** +1 [[BenjaminCarlyle]], atom:feed/title only
=== Discussion ===
=== Discussion ===
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
+
* [[BenjaminCarlyle]]: If one were to review a blog entry with [[hReview]] we would fill out the "fn" field with the atom:entry/title. This suggests to me that fn may be sufficient for this title usage. headline is more semantically specific, and does seem appropriate. It may be a line-ball call as to whether a new term is required, or whether the atom:entry context is sufficient to indicate the fn is also a headline.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
* BenjaminCarlyle: Are we considering atom:feed/title in this discussion? There is some suggestion that atom:title should be "fn", separate to any value of atom:entry/title.
-
* [[User:DavidJanes|DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
+
* [[DavidJanes]]: [http://www.ietf.org/rfc/rfc2426.txt vcard] defines "FN" to be "to specify the formatted text corresponding to the name of the object the vCard represents". If we reject FN, are we not making too subtle a distinction that the atom:title isn't the name of the post? I'll also note that the [http://www.ietf.org/rfc/rfc4287 domain experts] believe that the atom:title of an entry is pretty well the same sort of thing as the atom:title of a feed.
-
* [[User:Tantek|Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others.  See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p>  Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
+
* [[Tantek]]: First, I have re-evaluated using "fn" for feed:title per the information from Benjamin, David and others.  See [http://microformats.org/wiki/blog-post-brainstorming#feed_title this discussion for details].<p>Second, I now agree with DavidJanes and the domain experts that the title of a feed is very similar (if not nearly identical) in semantics to the title of an entry, neither of which can really be considered a name.</p><p>  Thus I am -1-ing "fn" for title for entry or feed since it doesn't mean the same thing.</p>
-
* [[User:DavidJanes|DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
+
* [[DavidJanes]]: to summarize (I think), Tantek argues on the link above that atom:title can and does include more than the name.
-
* [[User:DavidJanes|DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
+
* [[DavidJanes]]: we're now at the point where FN is the title of a movie, a DVD, and a book, but not the atom:title of an entry and definitely not the atom:title of a feed.
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
+
* [[BenjaminCarlyle]]: Entry and feed titles are both usually used as the name of the entry of feed, however examples exist where the entry title is [http://planet.freedesktop.org/ changed for republication] or is an auto-generated string (eg [http://www.advogato.org/person/cinamod/ date]). Headline is a good substitute at the entry level, and has a clear analogue in print. <p>If headline is selected for entry a different term would be required for feed. Headline cannot meaningfully be used for a feed title any more than the name of a newspaper can be called a headline. Working back from the newspaper analogue, I am aware of the use of both name or title to describe the analogous text. In the absence of evidence that a feed's desired title is ever anything but a human-created name for the blog, my support falls behind fn for feed title only. The danger remains that someone will supply non-name data as "fn" in order to "get it into the atom:title element". For this reason I remain open to further naming suggestions and to any example in the wild where this might already occur.</p><p>There has been some discussion that because the two are a single term in atom the domain experts consider the semantics to be the same. I suggest differently. The double use of title is inherited from rss, and has always been disambiguated by context. rfc4287 defines title as "a Text construct that conveys a human-readable title for an entry or feed", which conveys no useful semantics. Everything in a microformat is human-readable, and it isn't suprising that the semantics of title are equivalent to "title". To be honest, I would guess that the domain experts didn't give this issue a second thought.</p>
-
* [[User:DavidJanes|DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
+
* [[DavidJanes]]: '''RESOLVED''' Let's go with "headline". I'm not in love with it but so it goes. My thinking on this at this point is we won't find a good word that covers atom:entry/title and atom:feed/title and I like the idea of a (somewhat) domain specific word that captures the concept and (especially a big point for me now) it will make mixing hAtom with other uFs a little nicer.
-
* [[User:PaulBryson|PaulBryson]]: I like entry-title for it's clarity.  Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity.  In this case, it also adds a specificity that could be detrimental in the element's reuse.  Headline feels redundant with "heading", which is what the element should be.  Regardless, this is probably the best of the available choices.
+
* [[PaulBryson]]: I like entry-title for it's clarity.  Unfortunately, I also feel that hyphenating names together in a string adds unnecessary complexity.  In this case, it also adds a specificity that could be detrimental in the element's reuse.  Headline feels redundant with "heading", which is what the element should be.  Regardless, this is probably the best of the available choices.
== Entry Content (atom:content) ==
== Entry Content (atom:content) ==
Line 372: Line 372:
* <code>content</code> (Atom consistency)
* <code>content</code> (Atom consistency)
-
** -1 [[User:Tantek|Tantek]]
+
** -1 [[Tantek]]
-
** +1 [[User:DavidJanes|DavidJanes]]
+
** +1 [[DavidJanes]]
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
+
** +1 [[BenjaminCarlyle]]
** +1 [[RyanKing]]
** +1 [[RyanKing]]
-
** -1 [[User:ChrisCasciano|ChrisCasciano]]
+
** -1 [[ChrisCasciano]]
-
** -1 Kevin Marks - already too many in the wild
+
** -1 KevinMarks - already too many in the wild
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
* <code>description</code> (vCalendar, hCalendar, xFolk, hReview attempted consistency)
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 [[RyanKing]] - content has a different meaning in Atom than description in vCalendar, hCalendar, xFolk, hReview, we should avoid the confusion
** -1 Tantek - agreed with Ryan
** -1 Tantek - agreed with Ryan
-
** -1 Kevin Marks
+
** -1 KevinMarks
* <code>entry-content</code>
* <code>entry-content</code>
** +1 Niall Kennedy (proposed)
** +1 Niall Kennedy (proposed)
-
** +0.5 [[User:Tantek|Tantek]]
+
** +0.5 [[Tantek]]
-
** +1 Kevin Marks
+
** +1 KevinMarks
-
** +1 [[User:ChrisCasciano|ChrisCasciano]]
+
** +1 [[ChrisCasciano]]
* <code>atom-content</code>
* <code>atom-content</code>
-
** +0.5 [[User:Tantek|Tantek]]
+
** +0.5 [[Tantek]]
* <code>hcontent</code>
* <code>hcontent</code>
-
** -1 [[User:Tantek|Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.
+
** -1 [[Tantek]] - so far [http://microformats.org/wiki/hatom-issues#Entry_Published_.28atom:published.29 all the "h..." class names reflect root class names] and this may be a useful convention to continue even if it is not a requirement.
=== Discussion ===
=== Discussion ===
-
* [[User:Tantek|Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means.  In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item.  Whereas in hAtom is the thing itself.  The feed is the data is the item.  Thus it makes sense use a different class name than "description".  Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard.  Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
+
* [[Tantek]] - It turns out there is actually a very fine semantic distinction between the way "description" is used in vCalendar, hCalendar, xFolk, hReview, and what "content" means.  In short, those other microformats are all "about" something else, whether an actual event in spacetime, or another item.  Whereas in hAtom is the thing itself.  The feed is the data is the item.  Thus it makes sense use a different class name than "description".  Based on our [[naming-principles]], lacking an existing microformat term for this, we should use a term from a standard.  Since Atom uses "content", that is the logical name to bring over and use, whether or not it is "perfect" to capture the semantic we are trying to capture.
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
+
* [[BenjaminCarlyle]]: We may also have to consider forms of blogs that carry other media. An &lt;a rel="content" href="..."/&gt; form of content may also have to be considered, although this could still be embedded in a very short html content block. I'm not quite ready to commit to "content" yet, but I agree that description may be a little weak.
-
* [[User:ChrisCasciano|ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
+
* [[ChrisCasciano]] - I'd be a bit cautious about equating usage of the content class in the wild with the specific usage you'd adopt here -- that of the content of a particular item or entry. As a deveoper I know I've used the term content to designate larger page sections or as synonym for content body (or that which is not header, nav or footer). In most cases my usage has been via ID which is safe (though perhaps confusing usages of similar terms) but I'm certain I've also used it as a class to free up ID for more specific information on larger sites.
-
* [[User:Tantek|Tantek]]: Chris Casciano is right.  Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending.  I have changed my vote to -1 for "content".
+
* [[Tantek]]: Chris Casciano is right.  Not only that, but note the [http://code.google.com/webstats/2005-12/classes.html Google HTML survey] of about a billion documents found that many web authors use "content" as a class name already, for whatever purpose they are intending.  I have changed my vote to -1 for "content".
-
* [[User:Tantek|Tantek]]: I have added a few proposed alternatives based on discussions with various folks.  I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing.  I have split my vote among the new alternatives for now.
+
* [[Tantek]]: I have added a few proposed alternatives based on discussions with various folks.  I also checked [http://thesaurus.reference.com/search?q=content synonyms for content] but didn't find anything worth proposing.  I have split my vote among the new alternatives for now.
-
* [[User:ChrisCasciano|ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
+
* [[ChrisCasciano]] - added hcontent per irc conversation a few nights ago. Not necessarily my favorite, but it should probably be on the table for discussion.
-
* [[User:Kevin Marks|Kevin Marks]]  - I think entry-content is OK  - if we go by existing practice in blogs, post-body or post are common.
+
* [[KevinMarks]]  - I think entry-content is OK  - if we go by existing practice in blogs, post-body or post are common.
-
* [[User:ChrisCasciano|ChrisCasciano]]  - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')
+
* [[ChrisCasciano]]  - I'm behind entry-content as the least bad choice I've thought over.. atom-content doesn't 'read' generic enough for my tastes ('is it content for the page, or something just for atom export')
== Entry Summary (atom:summary) ==
== Entry Summary (atom:summary) ==
Line 411: Line 411:
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
* <code>description</code>, as used by VJOURNAL. It may be possible to interpret description as text longer than summary which is about the entry content. The hierarchy of detail would be summary (atom:title) -> description (atom:summary) -> content (atom:content)
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.   
** [[User:Kevin Marks|Kevin Marks]]: description is used ambiguously by RSS to mean 'content' or 'summary', and by hReview and hCalendar to mean 'content'. Doing this would recreate that ambiguity needlessly, when Atom distinguishes it clearly.   
-
** [[User:Tantek|Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL.  "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
+
** [[Tantek]]: Kevin's right, and not only that, "description" does NOT mean summary in VJOURNAL.  "description" means "full description" in vCalendar, iCalendar, [[hCalendar]], and also [[hReview]]. We must NOT use "description" to mean summary.
* <code>summary</code> (re-use from and consistency with Atom)
* <code>summary</code> (re-use from and consistency with Atom)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
* <code>content-summary</code> (Atom consistency avoiding hCalendar conflict)
Line 420: Line 420:
** +1 DavidJanes, my only concern being that they're not always excerpts
** +1 DavidJanes, my only concern being that they're not always excerpts
* <code>abstract</code>
* <code>abstract</code>
-
** +1 Kevin Marks
+
** +1 KevinMarks
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs
** +1 Ernest Prabhakar: this is what my blog software calls it, and how I use it in my own blogs
=== Discussion ===
=== Discussion ===
-
* [[User:Tantek|Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
+
* [[Tantek]]: Excerpt is by far the most frequent (>80%) use of summary, thus it makes sense to name it as such.
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making  it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
* [[User:Kevin Marks|Kevin Marks]]: Disagree - Atom allows summary to be distinct from content, though this is less usual. However, by using a class that means summary (eg abstract) we can convey an excerpt by making  it wholly within 'atom:content', or a separate abstract by putting it within the entry but not within 'content'
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
+
* [[BenjaminCarlyle]]: I have been trying to convince myself that atom:summary differs semantically from iCalendar summary. The "summary or subject" wording from rfc2445 is problematic, and it seems earlier microformats have taken the "subject" side. If we were to start from rfc2445 alone we might go the other way. In the end, though, webster.com defines summary as "covering the main points succinctly". atom:summary is not really consistent with that definition, so I'll swing my weight behind excerpt. On the subject of abstract, I think the semantics are such that "abstract" and "exerpt" are distinct (non-overlapping) sets. webster.com defines abstract as "a summary of points (as of a writing) usually presented in skeletal form". An exerpt is not a summary of points, and a summary of points is not an excerpt. I think tantek is simply suggesting that the 80% win in this case.
-
* [[User:Tantek|Tantek]]: Benjamin is correct.  The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
+
* [[Tantek]]: Benjamin is correct.  The vast majority (easily 80%+) of summaries in Atom, when they exist are excerpts. <p>In addition:</p>
** WordPress user interface calls it "excerpt"
** WordPress user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
** MovableType user interface calls it "excerpt"
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter.  Atom should have chosen "excerpt" as well based on this reason alone.
*: Thus, based on the principle of user-centered design (an instance of humans first, machines second) as well, in that a user *typing* into the "Excerpt:" field in the UI of their blogging tool, is communicating to the interface that "This is the ''excerpt'' of my blog post", "excerpt" is actually a ''BETTER'' name for this element than summary, or anything else for that matter.  Atom should have chosen "excerpt" as well based on this reason alone.
-
* [[User:ScottReynon|ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
+
* [[ScottReynen]]: I think there's a chance Tantek is mistaking cause and effect. Perhaps >80% of summaries are excerpts ''because'' two of the most popular publishing tools label the summaries as excerpts. Maybe we should be more sure WordPress and Movable type aren't actually confusing authors by using excerpt before following those examples.
-
* [[User:ChrisCasciano|ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.
+
* [[ChrisCasciano]]: The Textpattern interface also calls this field an excerpt.
== Entry Permalink (atom:link) ==
== Entry Permalink (atom:link) ==
Line 442: Line 442:
** +1 Tantek
** +1 Tantek
** +1 BenjaminCarlyle
** +1 BenjaminCarlyle
-
** +1 Kevin Marks
+
** +1 KevinMarks
=== Discussion ===
=== Discussion ===
-
* [[User:Kevin Marks|Kevin Marks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
+
* [[KevinMarks]]: I know this maps through to the atom name, but rel="bookmark" is the established standard for permalinks, and is included in the [http://www.w3.org/TR/html401/types.html#type-links| w3c list of rel's], so there is an Occam's Razor case for using this.
-
* [[User:DavidJanes|DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
+
* [[DavidJanes]]: I'd like input from everyone in this -- I'm torn really. Once I knock this thing into more of a complete state, I'll throw this out onto the mailing list for discussion
-
* [[User:DavidJanes|DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
+
* [[DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.
-
* [[User:Tantek|Tantek]]: Agreed with what Kevin wrote.  Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]].  The destination of the link is not really a "link" itself with respect to the current document/file.
+
* [[Tantek]]: Agreed with what Kevin wrote.  Also, rel="link" doesn't actually make sense when you do the analysis as described in the [[rel-faq]].  The destination of the link is not really a "link" itself with respect to the current document/file.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
* [[User:DavidJanes|David Janes]]: OK, I'm happy with this.'''STATUS - RESOLVED'''. We are using <code>rel="bookmark"</code>.
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
+
* [[BenjaminCarlyle]]: No real controversy here, unless you want to start giving blog entries or feeds vcards. A vcard could contain entry or feed title as fn, as well as url.
**  [[RyanKing]] non-issue, you can always use both.
**  [[RyanKing]] non-issue, you can always use both.
== Entry Published (atom:published) ==
== Entry Published (atom:published) ==
* <code>published</code> (Atom consistency)
* <code>published</code> (Atom consistency)
-
** +0.5 [[User:Tantek|Tantek]]
+
** +0.5 [[Tantek]]
-
** +1 [[User:DavidJanes|DavidJanes]]
+
** +1 [[DavidJanes]]
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
+
** +1 [[BenjaminCarlyle]]
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
* <code>dtpublished</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
-
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
+
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>VJOURNAL CREATED</code>
* <code>VJOURNAL CREATED</code>
=== Discussion ===
=== Discussion ===
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
+
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
-
* [[User:Tantek|Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user.  IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system.  It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
+
* [[Tantek]]: last-modified reflects the last time the page/file was actually modified, most likely by the user.  IMHO it is a 1:1 mapping of the "Date Modified" of a file in a file system.  It is a direct mapping of what date is shown for HTTP directory listings.<p>published is defined in Atom quite differently from that, and among the alternatives it seems best to take the name from Atom precisely.</p>
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
+
* [[BenjaminCarlyle]]: From the [[last-modified-brainstorming]] purpose statement, emphasis added. "To specify the date of publication and the date of modification of a web page (<em>or a part thereof</em>)"
-
* [[User:Tantek|Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
+
* [[Tantek]]: Note that Atom chose to drop "created" which is much more reflective of what current file systems etc. support.<p>The concept of "published" is distinct from a generic "created" notion, in that it indicates when the content was made public or made available to readers (even on intranets) which is often very different than when the author started typing the entry or even first saved the entry.</p>
-
* [[User:DavidJanes|DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
+
* [[DavidJanes]]: It's simple, it's clear, it's not being used it's not being used already. We can make [[last-modified-brainstorming|last-modified]] consistent afterwards
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
* [[RyanKing]]: I'm a bit wary of using someing so generic as 'published' for this. I need to go back throught [[blog-post-examples]] to see what conventions we have.
-
* [[User:Tantek|Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.
+
* [[Tantek]]: I have the same concerns as Ryan, and in addition, it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.
== Entry Updated (atom:updated) ==
== Entry Updated (atom:updated) ==
Line 480: Line 480:
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
* <code>dtupdated</code> (Atom consistency with [http://microformats.org/wiki/naming-principles#dt_properties dt unofficial pattern])
** +&frac12; Paul Bryson, Not as human readable
** +&frac12; Paul Bryson, Not as human readable
-
** +0.5 [[User:Tantek|Tantek]] (want to consider it, while we can)
+
** +0.5 [[Tantek]] (want to consider it, while we can)
* <code>last-modified</code>
* <code>last-modified</code>
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
** <code>VJOURNAL LAST-MODIFIED</code> (also HTTP)
Line 487: Line 487:
=== Discussion ===
=== Discussion ===
-
* [[User:PaulBryson|PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
+
* [[PaulBryson]]: I would prefer to maintain some consistency with already existing date naming conventions, but acknowledge that these aren't as clearly human readable as they could be.
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
+
* [[BenjaminCarlyle]]: I would still like to see a clear engagement with [[last-modified-brainstorming|last-modified]] before voting on this one.
-
* [[User:Tantek|Tantek]]: See discussion for published.  Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something.  Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
+
* [[Tantek]]: See discussion for published.  Updated is closer to last-modified than published is, however, upon careful reading of the definition of updated in Atom, it is clear that the user has the option of not changing the updated date even if they change the entry, e.g. by fixing a spelling error or something.  Thus there is an implied stronger meaning of "this entry has been semantically changed" that is a different enough semantic from last-modified as to justify a new name, and among the alternatives it seems best to take the name from Atom precisely.
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
+
* [[BenjaminCarlyle]]: From [[last-modified-brainstorming]] semantics:<p>"Since both Atom and HTTP define the last-modified date (or its equivalent) as a "user-defined" value, this microformat should have the same semantics. In other words, the value should represent the last instance that the resource was changed in a way deemed significant to the publisher/author, which is not neccessarily the same as a file-system modified date-time."</p>
-
* [[User:Tantek|Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
+
* [[Tantek]]: They are both user defined values but *different* user defined values. <p>It is VERY important to note this distinction because Atom chose to note it.</p><p>In the 99% case, file-system, web-server (HTTP) context, the last-modified date reflects the last time the *user* modified the file or page, WITHOUT consideration for whether or not the user wanted that change to reflect a change in the last-modified date.</p><p>Atom specifically allows for the exception that a user might not update the "updated" date, even when they change the underlying blog post, spelling corrections or whatever.</p><p>This is in stark contrast to the traditional application model, where in a word processor, even if you change one character and save, you change the file system last-modified date, and hence the HTTP last-modified headers.</p>
-
* [[User:DavidJanes|DavidJanes]]:  we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
+
* [[DavidJanes]]:  we can make [[last-modified-brainstorming|last-modified]] consistent afterwards
go back throught [[blog-post-examples]] to see what conventions we have.
go back throught [[blog-post-examples]] to see what conventions we have.
-
* [[User:Tantek|Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.
+
* [[Tantek]]: Similar to comments on "published", it may be useful from a parsing perspective to adopt a [http://microformats.org/wiki/naming-principles#dt_properties dt prefix convention] for ISO8601 typed properties.
== Entry Author (atom:author) ==
== Entry Author (atom:author) ==
Line 501: Line 501:
* <code>author</code> (Atom consistency)
* <code>author</code> (Atom consistency)
-
** +1 [[User:Tantek|Tantek]]
+
** +1 [[Tantek]]
-
** +1 [[User:BenjaminCarlyle|BenjaminCarlyle]]
+
** +1 [[BenjaminCarlyle]]
=== Discussion ===
=== Discussion ===
-
* [[User:BenjaminCarlyle|BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
+
* [[BenjaminCarlyle]]: I think an author concept is generally useful to microformats, so long as you can make it clear whether it is the author of the uf wrapper or the author of the uf content that is being described. I think any wavering over whether author and contributor are both required is probably a step outside the atom specification. This may be worthwhile, with an xfn-style external definition that could relate a person to a work... or even a rel-tag-based relationship. Can room be left open for both of these possibilities for future expansion, while still providing a clear author -> atom:author translation?
-
* [[User:Tantek|Tantek]]: My point is that in practice (>80% case again), contributor is not used.  Thus we should exclude it from hAtom in the first version.  However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
+
* [[Tantek]]: My point is that in practice (>80% case again), contributor is not used.  Thus we should exclude it from hAtom in the first version.  However, I am ok with ''reserving'' contributor with the intent that if it does somehow take off, we can add it later.
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?
* [[RyanKing]] is &lt;address&gt; not sufficient for 'author' semantics?
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].
* [[DimitriGlazkov]] I don't believe it is. The author of the feed and the author of the page (which is what &lt;address&gt; implies could be two different things. I just ran into this problem when trying to mark up a feed inside of a [http://fuzzycontent.com/index.php/2006/03/14/context-wants-to-be-free-too/ post].
Line 517: Line 517:
=== Discussion ===
=== Discussion ===
-
* [[User:Tantek|Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor".  We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
+
* [[Tantek]]: I recommend we postpone contributor from hAtom first version (thus the -1 before any choices), since the 80% case does not need "contributor".  We should reserve the name so we can add it later if we need it (thus the +1 on "contributor").
-
* [[User:DavidJanes|DavidJanes]]: '''RESOLUTION: DEFERRED'''
+
* [[DavidJanes]]: '''RESOLUTION: DEFERRED'''
== Entry Geo (geo:Point) ==
== Entry Geo (geo:Point) ==
-
* [[User:Brian|Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.
+
* [[Brian]]: GeoRSS is away to embed geo-position information into an entry, it is NOT part of Atom nor is this directly part of hAtom. This is an addition that can add value to a post. Microformats has already defined a way to add [[geo]] position data into HTML it is possible to combine the two in a single entry.
=== Ressources GeoRSS  ===
=== Ressources GeoRSS  ===
-
* [[User:Brian|Brian]]: [[http://www.georss.org/ GeoRSS]]
+
* [[Brian]]: [[http://www.georss.org/ GeoRSS]]
-
* [[User:Brian|Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]
+
* [[Brian]]: [[http://radar.oreilly.com/archives/2006/02/google_maps_extension_for_geor.html Google Maps Extension for GeoRSS]]
== Questions et Commentaires ==
== Questions et Commentaires ==
Line 531: Line 531:
=== Limites===
=== Limites===
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
* There seems to be nothing in the hAtom specification to supply metadata for the blog (title, description, url, feedurl). There is nothing defined for the encapsulation of comments, comment counts, or links to comment sections. The microformat would be much more useful with these capabilities added.-- [[User:Singpolyma|singpolyma]] 03:35, 3 Jan 2006 (PST)
-
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[User:DavidJanes|DavidJanes]]
+
** We've deliberately restricted this to being a "blog post" microformat at this point to make the problem manageable. Once the core elements are defined, we will consider extended the spec to cover as much as Atom does. Also note that microformats are compositable, thus, all these things could potentially be defined elsewhere with detriment to this standard. -- [[DavidJanes]]
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.
** [[RyanKing]]: '''STATUS:DEFERRED/REJECTED''': As David says, our scope is limited. After we can establish the core specification of hAtom, we'll look at adding more properties.
Line 540: Line 540:
* atom:author    -> hReview reviewer
* atom:author    -> hReview reviewer
-
[[User:Tantek|Tantek]]: "Pushed back" is the wrong direction here.
+
[[Tantek]]: "Pushed back" is the wrong direction here.
The right direction is "re-use" by new proposals/drafts.  If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.
The right direction is "re-use" by new proposals/drafts.  If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.
Line 548: Line 548:
=== hCards ===
=== hCards ===
-
[[User:DavidJanes|DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.
+
[[DavidJanes]]: Should hCards be required for the <code>&lt;address></code> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.
RESOLVED: MUST use hCard for author.
RESOLVED: MUST use hCard for author.
Line 557: Line 557:
** atom:uri &harr; hCard’s URI
** atom:uri &harr; hCard’s URI
* '''STATUS - OPEN'''. "MAY" is the answer.
* '''STATUS - OPEN'''. "MAY" is the answer.
-
* [[User:Tantek|Tantek]]: I think this should be MUST.  Atom should have referenced vCard for these semantics and made the mistake of making up their own terms.  Let's undo that mistake with hAtom.  Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]].  Thus we may want to just follow suit with hAtom as well.
+
* [[Tantek]]: I think this should be MUST.  Atom should have referenced vCard for these semantics and made the mistake of making up their own terms.  Let's undo that mistake with hAtom.  Also, [[hreview|hReview]] 0.3 has made hCard a MUST for the "reviewer" property, based on experience and [[hreview-feedback|feedback]].  Thus we may want to just follow suit with hAtom as well.
-
* [[User:DavidJanes|DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>
+
* [[DavidJanes]]: I had based the behavior on hReview 0.2. The problem is getting meaningful information into the blog templates and also I would appeal to parsimony, that is:<pre><nowiki><div class="author">bonehead</div></nowiki></pre><p>has an assumed defined mapping to</p><pre><nowiki><div class="author vcard"><span class="fn">bonehead</div></div></nowiki></pre><p>Since in many cases we're not going to get much more information than that, why add the verbosity? I note an analogous situation in hCard, where N.* are not required because they can be inferred algorithmically.</p>
=== Comparisons ===
=== Comparisons ===
Line 568: Line 568:
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.
I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.
-
--[[User:DrErnie|Ernie Prabhakar]]
+
--[[Ernie Prabhakar]]
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
* [[User:DavidJanes|David Janes]]: See the [[#Purpose]] section above. Basically that drove the design decision for the naming<p>'''STATUS - REJECTED'''. We're sticking with atom terminology (entry, content, summary).</p>
-
* [[User:Tantek|Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same.  The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not.  Note that you can overlay hAtom and S5 in the same markup.  Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.
+
* [[Tantek]]: As far as the analogy to S5, yes, there is an analogy, but that doesn't make them the same.  The semantics that are represented are different enough to let these evolve independently and see if content authors want them to converge or not.  Note that you can overlay hAtom and S5 in the same markup.  Anyone that is serious about converging these should *try* using both at the same time in a *real* slide presentation example and report back their experience.
=== Eléments répétés===
=== Eléments répétés===
Line 589: Line 589:
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?
Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?
-
-- [[User:BenjaminCarlyle|BenjaminCarlyle]]
+
-- [[BenjaminCarlyle]]
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --  
* [[User:DavidJanes|David Janes]]: The issue of "muse" and such is somewhat out of scope. However, I grasp your larger point -- what if we wanted to extend or compositie hAtom in the future. Given the 80-20 rule right now, my feeling is to set aside the problem and if it arises, define a <code>class~="opaque"</code> element. --  
-
* [[User:Tantek|Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.
+
* [[Tantek]]: See the [[mfo-examples]] document, and add further thoughts on this matter there.
==== Opacité du résumé et du contenu ====
==== Opacité du résumé et du contenu ====
-
[[User:DavidJanes|DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.
+
[[DavidJanes]]?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. [[last-modified-brainstorming]] introduces an idea of using <code>&lt;ins&gt;</code> and <code>&lt;del&gt;</code> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.
Perhaps content and summary should not be opaque, and instead rely on the [[mfo]] proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.
Line 619: Line 619:
=== rel-tag ===
=== rel-tag ===
-
Should hAtom use rel-tag for atom category elements? -- [[User:DavidJanes|DavidJanes]]
+
Should hAtom use rel-tag for atom category elements? -- [[DavidJanes]]
-
* [[User:Tantek|Tantek]]: IMHO yes.
+
* [[Tantek]]: IMHO yes.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* A version of this is currently implemented in hAtom2Atom.xsl, but the interpretation of rel-tag is not straightforward.
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.
* rel-tag uses the last path segment of a URI as its tag, for example <code>&lt;a href="http://apple.com/ipod" rel="tag">iPod</a></code>. Human-friendly content is permitted within the anchor. Atom defines three attributes on a category element. "term" is the category in use. "scheme" is a namespace for this category. "label" is a human-friendly text-only version of the category.

Current revision

Contents


hAtom 0.2

Cette section est destinées à discuter de ce que vous aimeriez voir dans la prochaine version de hAtom, c'est à dire 0.2.

Geo


Relation de rel-bookmark vers url+uid

Le concept de permalien est disponible dans hCard et hCalendar sous les classes url et uid. Cette combinaison fait correspondre la sémantique du permalien en indiquant que l'url devrait être déréréférencée pour trouver une version dynamique ou mise à jour du contenu, et que cette url est un id unique stable qui peut être utilisé pour identifier le contenu.

hAtom 0.1 utilise rel-bookmark pour le concept du permalien. L'état actuel du uid-brainstorming-fr indique que le concept permalien hCard et hCalendar doit être probablement utilisé dans les microformats subséquents. Ce peut être important de réconcilier hAtom avec cette trajectoire. Les réconciliations possibles comprennent :

1) Laisser les choses telles qu'elles sont. Les deux concepts des permaliens doivent être maintenus séparés.

2) Traiter les deux concepts comme équivalents. Permettre les deux dans hAtom et considérer permettre les deux dans d'autres formats. Par ex <a rel="bookmark" href="http://example.com/"> trouvera les valeurs uid et url si elles ne sont pas fournies explicitement.

3) Choisir l'un sur l'autre pour hAtom et peut être aussi pour les futurs microformats. "url uid" permet quelque plus grande liberté (l'uid peut être pointé comme un uid non url), mais ce n'est pas clair à cette étape si cette liberté est garanties ou recommandable à autoriser.

Fil XXX (atom:xxx)

section Gabarit : s'il y a quelque chose provenant clairement d'un Fil Atom que vous aimeriez dans hAtom 0.2, utilisez cette section comme un gabarit et répliquez là ici au bon endroit. Voir la section hAtom en dessous pour plus de détails.

Format Datetime (atom:updated et atom:published)

2006-05-23 soulevée Robert Bachmann

Atom exige l'utilisation de datetimes RFC3339 alors qu'hAtom 0.1 ne spécifie pas quels formats datetimes peuvent être utilisés.

Fil id (atom:id)

2006-04-01 soulevée par Robert Bachmann

atom:id est requis pour atom:feed. De ce fait ce devrait être disponibles aussi dans hAtom. Le permalien Feed devrait être utilisé comme le feed id.

Feed permalink (atom:permalink)

2006-04-01 soulevée Robert Bachmann

Je propose les règles suivantes :

* feed level = inside a Feed element but not inside an Entry element

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.


Feed updated (atom:updated)

2006-04-01 soulevé Robert Bachmann

atom:updated is required for atom:feed. Thus it should be available in hAtom to. I'm proposing the following rules:

Algorithm:

$a = array();
for each $entry in $feed {
    if ($entry.updated)
      $a.add(pad_datetime($entry.updated))
    else
      $a.add(pad_datetime($entry.published))
  }
$a.sort_by( datetime_to_utc($element) )
$feed_updated = $a[0];

* feed level = inside a Feed element but not inside an Entry element

Feed title (atom:title)

2006-04-01 souvlevée par Robert Bachmann

atom:title is required for atom:feed. Thus it should be available in hAtom to.

I'm proposing the following rules:

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 Robert Bachmann: Sorry, this was a "copy & paste" mistake. Fixed now.

Feed author et Entrée author (atom:author)

2006-04-01 soulevée par Robert Bachmann

I'm proposing the following rules for Feed author:

I'm proposing the following rules for entry author:

* feed level = inside a Feed element but not inside an Entry element

2006-04-17 Robert Bachmann: I replaced "the Feed is invalid hAtom" with "there is no Feed Author"

Entrée XXX (atom:xxx)

Template section: if there is something clearly from an Atom Entry that you'd like in hAtom 0.2, use this section as a template and replicate it in place here. See the hAtom 0.1 section below for more details.

Entrée id (atom:id)

2006-04-01 soulevée par Robert Bachmann

atom:id est requis pour atom:entry. De ce fait il devrait être dipsonible aussi dans hATom.

L'Entrée permalien devrait être utilisée comme l'id d'entrée.

2006-12-31 réponse par Emanla Eraton Non, ce ne devrait pas être un permalien. Ce devrait être un "tag:" id pour les entrées.


Author

author en tant que hCard est bien trop comme exigence

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

Autres Questions et Problématiques

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

Entry Updated Exigée ? -- Problématique de Blogger

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

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

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

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

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

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

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

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

Règles Brouillons pour plusieurs fils

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

Discussion de Règles Brouillons

hAtom 0.1

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

This page documents the issues that have been raised regarding the hAtom draft during the course of its development, and the resolutions of those issues (often with accompanying opinions).


Contributeurs

Feed (atom:feed)

RyanKing: STATUS: RESOLVED - 'hfeed' and not required (a la hcalendar)

Proposition Initiale

atomfeed (or rather, "atom-entry")

Alternatives

The above proposal was not fully accepted and some other possibilities were proposed:

Discussion

The feed is a root class name of hAtom, similar to "vcalendar" in hCalendar, thus it should be fairly unique, per the root class name naming-principles. - Tantek

Entry (atom:entry)

RyanKing: STATUS - RESOLVED - 'hentry'

Proposition Initiale

atomentry (or rather, "atom-entry")

Alternatives

The above proposal was not fully accepted. Other alternatives:

Discussion

Entrée Titre (atom:title)

RyanKing: STATUS - RESOLVED - going with 'entry-title, to be consistent with 'entry-content'

propositions

The title class is defined by hCard to mean "job title". Possible alternatives include (Please add to list):

Discussion

Entry Content (atom:content)

STATUS - RESOLVED going with entry-content


Discussion

Entry Summary (atom:summary)

STATUS - RESOLVED - going with 'entry-summary'

The summary class is defined by vCalendar, iCalendar, hCalendar, and also hReview, to mean "summary or title". Possible alternatives include (add to list):

Discussion

Entry Permalink (atom:link)

STATUS - RESOLVED - 'bookmark'

Discussion

Entry Published (atom:published)

Discussion

Entry Updated (atom:updated)

STATUS - RESOLVED - 'updated'

Discussion

go back throught blog-post-examples to see what conventions we have.

Entry Author (atom:author)

STATUS - RESOLVED - 'author' required, should use <address>

Discussion

Entry Contributor (atom:contributor)

Discussion

Entry Geo (geo:Point)

Ressources GeoRSS

Questions et Commentaires

Limites

Les relations vers les définitions hReview ont besoin de clarification

[DavidJanes?] hAtom will define terminology for the general act of publication that overlaps with hReview's terminology for the specific act of publishing a review of something. The following terms could be pushed back into hReview:

Tantek: "Pushed back" is the wrong direction here.

The right direction is "re-use" by new proposals/drafts. If you see anything in hReview that appears to overlap this new specification, the first thing to do is to see if you can reuse those terms from hReview in this new specification, not vice versa.

In addition, "published" does not mean the same as "dtreviewed" (you might write a restaurant review just after you eat there, but not actually "publish" it until later). "reviewer" is also a more precise semantic than "author", thus the two should not be collapsed.

hCards

DavidJanes: Should hCards be required for the <address> of the Entry Poster? MAY, MUST, SHOULD? Your thoughts please.

RESOLVED: MUST use hCard for author.

Comparisons

This seems precisely analogous to S5:

I'm all for NOT boiling the ocean, but these really seem like the same cup of tea.

--Ernie Prabhakar

Eléments répétés

Nous permettons à certains éléments d'être répétés, comme un Permalien d'Entrée, l'Entrée Publiée et le Titre de l'Entreée, même s'il peut y avoir au plus une valeur réelle. Nous fournissons des règles de "désambiguation" pour trouver quelle est la vraie valeur. Voir ici, ici, ici et ici.

Vos idées, svp... -- David Janes

STATUT - RESOU. La spec a des règles explicites de désambiguation pour tous ces items s'ils apparaissent plusieurs fois.

Opacité

Si vous avez des soucis à propos de l'opacité, ce qui veut dire arrêter l'interprétation en dessous de certains éléments hAtom, soulevez-les là.

Opacité des autres éléments microformat

How would we handle a case where someone wanted to provide a vcard under the class~=entry element for an individual who was neither author or contributor? Consider the hypothetical case where someone wanted to list their "muse" alongside article author and contributors. If this vcard included a title it might be included accidentally as an <atom:title>.

To summarise, Is it possible that other microformats found under the class~=entry or class~=feed elements need to be considered opaque?

-- BenjaminCarlyle

Opacité du résumé et du contenu

DavidJanes?: What one publisher considers the entry content may differ from another publisher's point of view. Is the content simply a div that does not contain any author/updated/published metadata etc, or could some of that metadata be relevant to the content as well as the entry? Consider updated. last-modified-brainstorming introduces an idea of using <ins> and <del> elements to indicate update time. Updates are also often included in entry content with further information. This suggests to me that the line of opaqueness is blurry.

Perhaps content and summary should not be opaque, and instead rely on the mfo proposal to avoid parsing into microformats below the content level. This approach would allow a single div to contain both "entry" and "content" classes should all metadata be considered content by the author, or would permit any other subset of the metadata to be considered content without repeating one's self.

Consider also the "read more"-style blog. The following nesting of div elements is illegal under current opacity rules: <div class="content"><div class="summary">...</div>...</div>

A further example is provided by _fil_ on #microformats, who uses the rel-tag microformat within his atom:content to be handled as tags in his feed reader.

Identification

The current spec under Schema:Nomenclature:Entry includes the text: "if practical, also define id="unique-identifier" to the Entry" What should be done with this id by parsers? How does this interact (if at all) with the interpretation of a rel=bookmark within the entry?

Also, how should a feed <id> element be filled out from a hAtom source document? Is a rel=bookmark at the feed level required?

The id elements in atom are supposed to survive all future movements of the blog to new hosting arrangements and the like. Are current feed URLs or even rel=bookmarks solid enough?

STATUS - OPEN.

HTML Title

Atom permits title to be either plain text or html. hAtom2Atom.xsl currently uses a plain text translation, and some feed readers seem not to handle html titles well (liferea does not normalize-whitespace, for example). Should a hAtom title element become a plain text or a html atom title? If so, should a subset of html be passed through rather than all html (including id, etc)?

rel-tag

Should hAtom use rel-tag for atom category elements? -- DavidJanes

Excess disambiguation rules?

Disambiguation rules apply to feed and entry title, and hAtom2Atom.xsl implements these. Rules also apply to permalink, published, and updated. These are currently not implemented. If they appear multiple times in the source document they are repeated multiple times.

It is clear that the data relating to these fields may be repeated within a hAtom entry, however the class notation may not. Only one element need be marked with rel="bookmark". Only one need be marked published, and one updated. Should the disambiguation rules be removed and only one element be allowed for each value, or is there value to the publisher in marking different elements with the hAtom class names?

Dépendances

mfo

Does this specification depend on acceptance of a hAtom-compatible mfo? See mfo-examples-fr.

Is atom:content necessary?

Atom's structure is built up around separating content and other metadata. atom:updated, atom:author, and the like are separate from atom:content any may contain repeated data. Microformats are built around bringing the content and the metadata back together. Is there are genuine use case for identifying only part of the atom entry as content? Presumably the whole html entry is fit for human consumption, or it wouldn't be part of a microformatted web page. Could that whole html snippet be used as the content?

Published as default value for atom:updated

It seems to be common practice to include an "updated" section within the main blog content to track updates to an atom:entry as they occur. It is less common to include a value for atom:published within atom:content. atom:published is usually provided by a machine, but atom:updated is often provided by a human.

I suggest that if a value of published exists but no value for updated exists that the required updated field be filled out from the optional published field. I think this would make changing the required value of updated easier for publishers. Also, several updates may occur to a single entry. I suggest that a disambiguation rule be applied such that the the latest timestamp of any updated field be used if several exist. The overal parser semantics would therefore be:

  1. If multiple updated fields exist, choose the most recent one.
  2. If only one updated field exists, choose that value.
  3. If no updated field exists but a published field exists, use the published value for atom:updated.
+ 1 Robert Bachmann

Désigner l'auteur de la page

(2006-02-07 raised by Robert Bachmann)

“[I]f an Entry has 0 Entry Author elements, the "logical Entry Author" is assumed to be the author of the XHTML page”

(2006-02-13 example by Chris Casciano) There is a live case showing this issue at http://chunkysoup.net - The posts are now hatom'd but since I am the only author the individual entries do not repeast the info with each entry. I do have an hcard with my (the page author's) information in the fotter of the page, but at the moment it is not designated via the <address> element due to sematics/content. FWIW, it is also outside of the block designated as the hfeed.

Proposition

Entry Updated Obligé ? -- Blogger

See Also

Gabarit

SVP utilisez ce format (copiez et coller ça à la fin de la liste pour ajouter vos problématiques) :

hatom-issues-fr was last modified: Tuesday, May 1st, 2007

Views