Difference between revisions of "hatom-brainstorming"

From Microformats Wiki
hatom-brainstorming
Jump to navigation Jump to search
m
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
<h1> hAtom Brainstorming </h1>
+
{{DISPLAYTITLE:hAtom Brainstorming }}
  
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 ==
 
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)
 +
*** [[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>
  
 
== '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 33:
 
# 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 43:
  
 
=== 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>
  
  
 
== 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-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>
Line 57: Line 62:
 
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)
 +
 +
<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>
 +
 +
== 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
 +
 +
== HTML5 time element ==
 +
 +
hAtom 0.2 should explicitly recommend the preferred use of the [[HTML5]] <code>&lt;time&gt;</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 ==
 +
* [[hAtom]]
 +
* [[hatom-issues]]

Latest revision as of 16:23, 18 July 2020


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

Entry Updated Required? -- Blogger Issue

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)

  • User: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 title="day month-name year, hour12:minute ampm tz") but I think this is asking too much from creators and parsers.
    • 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. Tantek 00:02, 26 August 2009 (UTC)
      • 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.

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

The hAtom 0.1 spec states the following 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

Draft Rules for multiple feeds

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

  • If there is only one feed on a page spec+parsing rules from 0.1 apply
  • If there are multiple feeds, each feed should explicitly define the root hfeed element with both class="hfeed" and a fragment identifier (id).
  • Specific feeds can be addressed via their fragment id.
  • If no fragment id is specified for a page with multiple hatom feeds then their content is merged via atom's SOURCE semantics

Discussion of Draft Rules

  • 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: 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)
  • Chris Casciano's rules for multiple feeds look good to me, and I agree with their inclusion in hAtom 0.2. - Tantek 00:02, 26 August 2009 (UTC)


User comment entries

A user comment (e.g., in blogs, wikis, forms) can be marked as an 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 in-reply-to from 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 rel="in-reply-to" href="#comment_20080902144745">Parent</a>

hEntries that use rel="in-reply-to" can be considered as a comment entry in response to a parent entry in the threaded conversation (e.g., in blogs, wikis, forms).

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

By reusing in-reply-to, we can solve the microformats representation for user comments [1], [2], [3].

--Sarven Capadisli 21:25, 3 Oct 2008 (PDT)

  • I like Sarven's approach to comment entries. - Tantek 00:02, 26 August 2009 (UTC)
  • See also the comment microformats effort, and perhaps incorporate that analysis here.

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-design-pattern).

The use of rel-design-pattern works well for re-use and harmonizes nicely with rfc-4287. 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 class="url" instead.
  • The url property is already well used and understood by authors in hCard 1.0, hCalendar 1.0, hReview 0.4 (in progress), 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.

Tantek 00:02, 26 August 2009 (UTC)

  • I started trying to mark up hEntry items on the microformats wiki, and ran into this need. - Tantek 00:02, 26 August 2009 (UTC)

geo for georss

Per an issue raised originally by Brian Suda in hCard issues:

  • 2006-02-03 raised by Brian
    1. We can use the Geo microformat in hAtom 0.1 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

HTML5 time element

hAtom 0.2 should explicitly recommend the preferred use of the Microformats in HTML5 <time> element for all datetime properties, e.g. "published" and "updated", especially in concert with the Value Class Pattern:

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

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

see also