hatom-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:23:51Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:23, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~hAtom Brainstorming ~~</entry-title>~~		{{DISPLAYTITLE:hAtom Brainstorming }}

	Brainstorming/discussion of fixes and/or enhancements for hAtom 0.2.		Brainstorming/discussion of fixes and/or enhancements for hAtom 0.2.

Tantek: let's strongly recommend the use of the HTML5 time element in hAtom

2011-07-15T02:15:15Z

let's strongly recommend the use of the HTML5 time element in hAtom

← Older revision		Revision as of 02:15, 15 July 2011
Line 94:		Line 94:
	*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element		*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
	# ACCEPTED DOCUMENTATION. Yes, this should be documented in [[hatom-examples]], perhaps after some [[hatom-brainstorming]] about how authors should do it and how hAtom processors should process it. -Tantek		# ACCEPTED DOCUMENTATION. Yes, this should be documented in [[hatom-examples]], perhaps after some [[hatom-brainstorming]] about how authors should do it and how hAtom processors should process it. -Tantek

			== HTML5 time element ==

			hAtom 0.2 should explicitly recommend the preferred use of the [[HTML5]] <code><time></code> element for all datetime properties, e.g. "published" and "updated", especially in concert with the [[value-class-pattern]]:

			<source lang=html4strict>
			<span class="published">
			<time class="value">1:02</time> on <time class="value">2011-07-14</time>
			</span>
			</source>

			real-world example from: http://tantek.com/2011/195/t2/google-profiles-support-hcard-rel-me-microformats

	== see also ==		== see also ==
	* [[hAtom]]		* [[hAtom]]
	* [[hatom-issues]]		* [[hatom-issues]]

Tantek: added brainstorm about geo for GeoRSS

2009-10-18T17:18:26Z

added brainstorm about geo for GeoRSS

← Older revision		Revision as of 17:18, 18 October 2009
Line 88:		Line 88:
	* I started trying to mark up hEntry items on the microformats wiki, and ran into this need. - [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)		* I started trying to mark up hEntry items on the microformats wiki, and ran into this need. - [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
	</div>		</div>

			== geo for georss ==
			Per an issue raised originally by Brian Suda in [[hcard-issues]]:
			*2006-02-03 raised by Brian
			*# We can use the [[geo]] microformat in [[hatom]] to represent GeoRSS element
			# ACCEPTED DOCUMENTATION. Yes, this should be documented in [[hatom-examples]], perhaps after some [[hatom-brainstorming]] about how authors should do it and how hAtom processors should process it. -Tantek

			== see also ==
			* [[hAtom]]
			* [[hatom-issues]]

JonathanMalek: synthesis of data: introducing uncertainty?

2009-08-29T18:36:10Z

synthesis of data: introducing uncertainty?

← Older revision		Revision as of 18:36, 29 August 2009
Line 10:		Line 10:
	** [[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 lenient.		** [[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 lenient.
	** From experience with authors, I think all properties should be made optional in hAtom 0.2, and hAtom 0.2 must specify how hAtom to Atom converters can synthesize any required elements/attributes in Atom. [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)		** From experience with authors, I think all properties should be made optional in hAtom 0.2, and hAtom 0.2 must specify how hAtom to Atom converters can synthesize any required elements/attributes in Atom. [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
			*** [[User:JonathanMalek\|JonathanMalek]] 18:36, 29 August 2009 (UTC): Is there a risk that synthesis of data (for instance, date) could cause trust issues for the entire format? Since the recommendation is that all properties are made optional, then any required property in Atom could be synthesized, which potentially introduces uncertainty/ambiguity into the data. I suppose a counter to that would be that any data is better than no data, which is still better than false or noise data, and so properties should be relaxed to both encourage adoption and reduce noise.
	</div>		</div>

Tantek: for hAtom 0.2

2009-08-26T00:02:57Z

for hAtom 0.2

← Older revision		Revision as of 00:02, 26 August 2009
Line 1:		Line 1:
	<entry-title>hAtom Brainstorming </entry-title>		<entry-title>hAtom Brainstorming </entry-title>

	Brainstorming/discussion of fixes and/or enhancements to hAtom.		Brainstorming/discussion of fixes and/or enhancements for hAtom 0.2.

	== Entry Updated Required? -- Blogger Issue ==		== Entry Updated Required? -- Blogger Issue ==

Tantek: clean up formatting a bit, add discussion sections, add url uid proposal

2009-08-26T00:02:32Z

clean up formatting a bit, add discussion sections, add url uid proposal

← Older revision		Revision as of 00:02, 26 August 2009
Line 1:		Line 1:
	<h1> hAtom Brainstorming </h1>		<entry-title>hAtom Brainstorming </entry-title>

	Brainstorming/discussion of fixes and/or enhancements to hAtom.		Brainstorming/discussion of fixes and/or enhancements to hAtom.
Line 6:		Line 6:
	The [[hatom\|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\|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)

			<div class="discussion">
	* [[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 lenient.
			** From experience with authors, I think all properties should be made optional in hAtom 0.2, and hAtom 0.2 must specify how hAtom to Atom converters can synthesize any required elements/attributes in Atom. [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
			</div>

	== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ==		== 'MAY have multiple Feed elements' -- details and viability of multiple feeds ==
	The [[hatom\|hAtom]] 0.1 spec states the ~~follwing~~ two items about the Feed element:		The [[hatom\|hAtom]] 0.1 spec states the following two items about the Feed element:

	# the Feed element is optional and, if missing, is assumed to be the page		# the Feed element is optional and, if missing, is assumed to be the page
Line 29:		Line 32:
	# 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)		# 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)
	# [[User:ChrisCasciano\|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]		# [[User:ChrisCasciano\|Chris Casciano]] (2006-07-24): A good chat session on this issue can be found [http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929 here]


	=== Draft Rules for multiple feeds ===		=== Draft Rules for multiple feeds ===
Line 40:		Line 42:

	=== Discussion of Draft Rules ===		=== Discussion of Draft Rules ===
			<div class="discussion">
	* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?		* Issue: what is the result of trying to address a feed at a non-existing fragment identifier? Same as no fragment id specified, or a not found error?
	* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?		* Issue: for authors, is there any way we can control a redirect for a feed addressed via fragment id?
	* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?		* Issue: are there any other long term management issues or other authoring considerations we need to think about for 0.2?
	* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)		* Issue: is the reliance on class + id too strict? we may be losing other non-ambiguous constructs for sake of simplicity (e.g. roots are [1]body [2] hfeed w/id or [1] body w/ id [2] hfeed w/id)
			* Chris Casciano's rules for multiple feeds look good to me, and I agree with their inclusion in hAtom 0.2. - [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
			</div>


Line 60:		Line 64:

	--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)		--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

			<div class="discussion">
			* I like Sarven's approach to comment entries. - [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
			* See also the [[comment]] microformats effort, and perhaps incorporate that analysis here.
			</div>

			== url uid properties ==
			Proposal: add the "url" and "uid" properties as another way for authors to indicate a post permalink (in addition to hAtom's use of [[rel-bookmark]]).

			The use of [[rel-bookmark]] works well for re-use and harmonizes nicely with [[Atom]]. However, there are some reasons that it would be nice to also have an explicit "url" property for inclusion of URLs to media item resources:

			* In MediaWiki - it is difficult to set the "rel" attribute on a link, and thus it is helpful to have the alternative of using <code>class="url"</code> instead.
			* The <code>url</code> property is already well used and understood by authors in [[hCard]], [[hCalendar]], [[hReview]], etc.

			How it would work:

			If there is no rel-bookmark for an hEntry, then an element with property names of "url" and "uid" would be used to determine the permalink for the hEntry.

			[[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)

			<div class="discussion">
			* I started trying to mark up hEntry items on the microformats wiki, and ran into this need. - [[User:Tantek\|Tantek]] 00:02, 26 August 2009 (UTC)
			</div>

Csarven at 15:10, 5 October 2008

2008-10-05T15:10:15Z

← Older revision		Revision as of 15:10, 5 October 2008
Line 57:		Line 57:
	hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)		hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)

	By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment]], [http://microformats.org/wiki/comment-brainstorming].		By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment], [http://microformats.org/wiki/comment-brainstorming].

	--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)		--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)

Csarven at 06:18, 4 October 2008

2008-10-04T06:18:24Z

← Older revision		Revision as of 06:18, 4 October 2008
Line 48:		Line 48:

	== User comment entries ==		== User comment entries ==
	A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-~~replies~~-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:		A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-reply-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
	<pre><nowiki>		<pre><nowiki>
	<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>		<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>

Csarven at 06:16, 4 October 2008

2008-10-04T06:16:50Z

← Older revision		Revision as of 06:16, 4 October 2008
Line 48:		Line 48:

	== User comment entries ==		== User comment entries ==
	A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-replies-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-~~repl~~-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:		A user comment (e.g., in blogs, wikis, forms) can be marked as an [http://microformats.org/wiki/hatom hAtom] since it has a similar content pattern. A way to differentiate an hEntry (e.g., a blog post) from another hEntry (e.g., a user comment) can be done reusing [http://tools.ietf.org/html/rfc4685#section-3 in-replies-to] from [http://tools.ietf.org/html/rfc4685 Atom Threading Extensions]. It provides a mechanism to indicate that an entry is a response to another resource. rel="in-reply-to" can indicate that the current hEntry is a reply to another hEntry and has a reference point @href:
	<pre><nowiki>		<pre><nowiki>
	<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>		<a rel="in-reply-to" href="#comment_20080902144745">Parent</a>

Csarven at 06:15, 4 October 2008

2008-10-04T06:15:48Z

← Older revision		Revision as of 06:15, 4 October 2008
Line 55:		Line 55:
	hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).		hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).

	hEntries that are chronologically listed can all use rel="in-~~repl~~-to" and refer to the root hEntry (e.g., blog post, form post)		hEntries that are chronologically listed can all use rel="in-reply-to" and refer to the root hEntry (e.g., blog post, form post)

	By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment]], [http://microformats.org/wiki/comment-brainstorming].		By reusing in-reply-to, we can solve the microformats representation for user comments [http://microformats.org/wiki/mfcomment], [http://microformats.org/wiki/hcomment]], [http://microformats.org/wiki/comment-brainstorming].

	--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)		--[[User:Csarven\|Sarven Capadisli]] 21:25, 3 Oct 2008 (PDT)