hatom-brainstorming: Difference between revisions
mNo edit summary |
(clean up formatting a bit, add discussion sections, add url uid proposal) |
||
Line 1: | Line 1: | ||
< | <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 | ** [[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 | 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> |
Revision as of 00:02, 26 August 2009
<entry-title>hAtom Brainstorming </entry-title>
Brainstorming/discussion of fixes and/or enhancements to hAtom.
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)
- 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)
'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:
- the Feed element is optional and, if missing, is assumed to be the page
- 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):
- Can a unique reference be made to each feed? Are there ambiguous references?
- 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.
- 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.
- 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?
- 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)
- 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)
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
class="url"
instead. - The
url
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.
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)