hatom-issues-fr - Revision history

Tantek: Reverted edit of Gazza, changed back to last version by ChristopheDucamp

2007-05-01T23:22:24Z

Reverted edit of Gazza, changed back to last version by ChristopheDucamp

Gazza: Fixed broken links

2007-05-01T12:57:27Z

Fixed broken links

← Older revision		Revision as of 12:57, 1 May 2007
Line 172:		Line 172:
	** [[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.

	* [[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: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"
	** [[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.		** [[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.
	** [[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
Line 335:		Line 335:
	* <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.		** [[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.
	** -1 [[User:~~KevinMarks~~\|~~KevinMarks~~]] (clashes with atom)		** -1 [[User:Kevin Marks\|Kevin Marks]] (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 343:		Line 343:
	* <code>headline</code>		* <code>headline</code>
	** +1 [[User:Tantek\|Tantek]]		** +1 [[User:Tantek\|Tantek]]
	** +1 [[User:~~KevinMarks~~\|~~KevinMarks~~]], as this is what they are most like in blogposts [[User:~~KevinMarks~~\|Kevin Marks]]		** +1 [[User:Kevin Marks\|Kevin Marks]], as this is what they are most like in blogposts [[User:Kevin Marks\|Kevin Marks]]
	** +1 [[User:BenjaminCarlyle\|BenjaminCarlyle]], atom:entry/title only		** +1 [[User:BenjaminCarlyle\|BenjaminCarlyle]], atom:entry/title only
	** +½ [[User:DavidJanes\|DavidJanes]], atom:entry/title only		** +½ [[User:DavidJanes\|DavidJanes]], atom:entry/title only
Line 377:		Line 377:
	** +1 [[RyanKing]]		** +1 [[RyanKing]]
	** -1 [[User:ChrisCasciano\|ChrisCasciano]]		** -1 [[User:ChrisCasciano\|ChrisCasciano]]
	** -1 ~~KevinMarks~~ - already too many in the wild		** -1 Kevin Marks - 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 ~~KevinMarks~~		** -1 Kevin Marks
	* <code>entry-content</code>		* <code>entry-content</code>
	** +1 Niall Kennedy (proposed)		** +1 Niall Kennedy (proposed)
	** +0.5 [[User:Tantek\|Tantek]]		** +0.5 [[User:Tantek\|Tantek]]
	** +1 ~~KevinMarks~~		** +1 Kevin Marks
	** +1 [[User:ChrisCasciano\|ChrisCasciano]]		** +1 [[User:ChrisCasciano\|ChrisCasciano]]
	* <code>atom-content</code>		* <code>atom-content</code>
Line 400:		Line 400:
	* [[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.		* [[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.
	* [[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.		* [[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.
	* [[User:~~KevinMarks~~\|~~KevinMarks~~]] - I think entry-content is OK - if we go by existing practice in blogs, post-body or post are common.		* [[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.
	* [[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')		* [[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')

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 ~~KevinMarks~~		** +1 Kevin Marks
	** +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

Line 442:		Line 442:
	** +1 Tantek		** +1 Tantek
	** +1 BenjaminCarlyle		** +1 BenjaminCarlyle
	** +1 ~~KevinMarks~~		** +1 Kevin Marks

	=== Discussion ===		=== Discussion ===
	* [[User:~~KevinMarks~~\|~~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: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.
	* [[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		* [[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
	* [[User:DavidJanes\|DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.		* [[User:DavidJanes\|DavidJanes]] Also, "link" is horribly generic and is in fact modified through the "rel" attribute in Atom.

Gazza: Fixed broken link

2007-05-01T12:45:04Z

Fixed broken link

Show changes

Gazza: /* Comparisons */ Fixed broken link

2007-05-01T12:13:01Z

Comparisons: Fixed broken link

← Older revision		Revision as of 12:13, 1 May 2007
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.

	--[[Ernie Prabhakar]]		--[[User:DrErnie\|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>

Gazza: /* Alternatives */ Fixed broken links

2007-05-01T11:42:59Z

Alternatives: Fixed broken links

← Older revision		Revision as of 11:42, 1 May 2007
Line 310:		Line 310:

	* <code>entry</code> (Atom consistency)		* <code>entry</code> (Atom consistency)
	** +1 [[MarkRickerby]]		** +1 [[User:MarkRickerby\|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 [[DavidJanes]]		** +1 [[User:DavidJanes\|DavidJanes]]
	** +1 [[Tantek]]		** +1 [[User:Tantek\|Tantek]]
	** +1 [[BenjaminCarlyle]]		** +1 [[User:BenjaminCarlyle\|BenjaminCarlyle]]
	** +1 [[RyanKing]]		** +1 [[User:RyanKing\|RyanKing]]
	** +1 [[MarkRickerby]]		** +1 [[User:MarkRickerby\|MarkRickerby]]
	** +1 [[DannyAyers]]		** +1 [[User:DannyAyers\|DannyAyers]]
	* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar\|hCalendar]])		* <code>vjournal</code> (reuse from vCalendar/iCalendar RFC 2445/[[hcalendar\|hCalendar]])
	** -1 [[RyanKing]] - though its a standard, it doesn't have widespread adoption		** -1 [[User:RyanKing\|RyanKing]] - though its a standard, it doesn't have widespread adoption

	==== Discussion ====		==== Discussion ====
	* [[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>		* [[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>

	== Entrée Titre (atom:title) ==		== Entrée Titre (atom:title) ==

Gazza: /* Discussion */ Fixed broken link

2007-05-01T11:39:04Z

Discussion: Fixed broken link

← Older revision		Revision as of 11:39, 1 May 2007
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]]. - [[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]]. - [[User:Tantek\|Tantek]]

	== Entry (atom:entry) ==		== Entry (atom:entry) ==

Gazza: Fixed broken links

2007-05-01T11:38:19Z

Fixed broken links

← Older revision		Revision as of 11:38, 1 May 2007
Line 293:		Line 293:
	<code>atomentry</code> (or rather, "atom-entry")		<code>atomentry</code> (or rather, "atom-entry")

	* [[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.		* [[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.
	* 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)
	*** [[DannyAyers]]: My point exactly, but it wouldn't be the end of the world if the prefix was there - not really more than aesthetics...		*** [[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...
	*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>		*** <del>'''STATUS - RESOLVED'''. We're going with "entry".</del>
	*** [[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:		*** [[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:
	**** atom-entry		**** atom-entry
	**** hentry		**** hentry

Gazza: Fixed broken links

2007-05-01T11:37:15Z

Fixed broken links

Gazza: Fixing broken links

2007-05-01T11:33:22Z

Fixing broken links

← Older revision		Revision as of 11:33, 1 May 2007
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 <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 <div class="author"> element.
	** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.		** [[User: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.
	** [[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.

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

	== Autres Questions et Problématiques ==		== Autres Questions et Problématiques ==

ChristopheDucamp at 18:50, 27 February 2007

2007-02-27T18:50:17Z

← Older revision		Revision as of 18:50, 27 February 2007
Line 23:		Line 23:
	== Fil <i>XXX</i> (atom:<i>xxx</i>) ==		== Fil <i>XXX</i> (atom:<i>xxx</i>) ==

	~~Template~~ section: ~~if there is something clearly from an Atom~~ ''~~Feed~~'' ~~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~~.		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:<i>updated</i> et atom:<i>published</i>) ==		== Format Datetime (atom:<i>updated</i> et atom:<i>published</i>) ==
	<small>2006-05-23 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-05-23 soulevée [[User:RobertBachmann\|Robert Bachmann]]</small>

	Atom ~~requires the use~~ RFC3339 ~~datetimes, while~~ hAtom 0.1 ~~does not specify which datetime~~ formats ~~may be used~~.		Atom exige l'utilisation de datetimes RFC3339 alors qu'hAtom 0.1 ne spécifie pas quels formats datetimes peuvent être utilisés.

	== ~~Feed~~ <i>id</i> (atom:<i>id</i>) ==		== Fil <i>id</i> (atom:<i>id</i>) ==
	<small>2006-04-01 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-04-01 soulevée par [[User:RobertBachmann\|Robert Bachmann]]</small>

	atom:<i>id</i> ~~is required for~~ atom:feed. ~~Thus it should be available in~~ hAtom to.		atom:<i>id</i> est requis pour atom:feed. De ce fait ce devrait être disponibles aussi dans hAtom.
	~~The~~ Feed ~~permalink should be used as the~~ feed id.		Le permalien Feed devrait être utilisé comme le feed id.

	== Feed <i>permalink</i> (atom:<i>permalink</i>) ==		== Feed <i>permalink</i> (atom:<i>permalink</i>) ==
	<small>2006-04-01 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-04-01 soulevée [[User:RobertBachmann\|Robert Bachmann]]</small>

	~~I'm proposing the following rules~~:		Je propose les règles suivantes :

	* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*		* a Feed Permalink element is identified by [[rel-bookmark]] at the feed level*
Line 61:		Line 61:

	== Feed <i>updated</i> (atom:<i>updated</i>) ==		== Feed <i>updated</i> (atom:<i>updated</i>) ==
	<small>2006-04-01 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-04-01 soulevé [[User:RobertBachmann\|Robert Bachmann]]</small>

	atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to.		atom:<i>updated</i> is required for atom:feed. Thus it should be available in hAtom to.
Line 88:		Line 88:

	== Feed <i>title</i> (atom:<i>title</i>) ==		== Feed <i>title</i> (atom:<i>title</i>) ==
	<small>2006-04-01 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-04-01 souvlevée par [[User:RobertBachmann\|Robert Bachmann]]</small>

	atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to.		atom:<i>title</i> is required for atom:feed. Thus it should be available in hAtom to.
Line 114:		Line 114:

	== Feed <i>author</i> et Entrée author (atom:<i>author</i>) ==		== Feed <i>author</i> et Entrée author (atom:<i>author</i>) ==
	<small>2006-04-01 ~~raised by~~ [[User:RobertBachmann\|Robert Bachmann]]</small>		<small>2006-04-01 soulevée par [[User:RobertBachmann\|Robert Bachmann]]</small>

	I'm proposing the following rules for Feed author:		I'm proposing the following rules for Feed author:

← Older revision		Revision as of 11:33, 1 May 2007
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 <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 <div class="author"> element.
	** [[Tantek]] I don't believe the "can't possibly" statement. Please provide a URL to a concrete example that you think you can't possibly reformat into an hCard so we can all take a look.		** [[User: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.
	** [[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.

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

	== Autres Questions et Problématiques ==		== Autres Questions et Problématiques ==

← Older revision		Revision as of 11:37, 1 May 2007
Line 255:		Line 255:
	<code>atomfeed</code> (or rather, "atom-entry")		<code>atomfeed</code> (or rather, "atom-entry")

	* [[DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?		* [[User:DannyAyers\|DannyAyers]]: But what does 'feed' mean in the context of a HTML page? Doesn't the <head> element cover the corresponding semantics?
	* [[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
	* [[DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases		* [[User:DavidJanes\|DavidJanes]]: I'm going to more explicitly recognize that the XHTML document ''may'' act as an implicit feed in many cases
	* [[DavidJanes]]: A Feed is a group of related Entries; what defines the relationship is entirely up to the author of the blog, except to note that if they were to place them together in the same Atom syndication feed, you'd do the same in the XHTML		* [[User: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
	* [[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.
	* [[Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.		* [[User:Tantek\|Tantek]]: Ernie is precisely correct. The vevent/vcalendar :: entry/feed analogy is precisely correct.
	* [[DannyAyers]]: The multi-feed point makes sense, but if this data appears on a regular HTML page the question remains, does "feed" make sense? (Maybe just naming aesthetics again)		* [[User: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)
	* [[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.) --
	* [[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]]: Agreed with David. Not only does it make sense, it is a bad idea to consider renaming something like that for "aesthetics".
	* [[Tantek]]: Per the root-class-name naming practices, we should seriously consider a more "unique" name, e.g. some possibilities:		* [[User:Tantek\|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