[uf-discuss] hAtom look-see

Chris Casciano chris at placenamehere.com
Thu Mar 23 06:14:51 PST 2006


On Mar 22, 2006, at 12:36 PM, Robert Bachmann wrote:

> Hi Chris,
>
> Thanks for your feedback.
> Please note that feed title, feed updated, feed id and feed link
> aren't covered by hAtom 0.1.
> So we (the stylesheet authors) needed to come up with our own  
> extraction
> methods, which I'll outline with some pseudo-code.
>

As I posed in IRC yesterday -- is it really up to the stylesheet /  
authors of consumers to determine this stuff? Almost definitely this  
should become part of the spec/wiki and consensus reached -- both for  
the benefit of tool authors -- but also the benefit of page builders  
like myself who are trying to reconcile differences between hAtom and  
the Atom spec and wondering how they work together..

Since then I've relaunched my site ChunkySoup.net --  
http://chunkysoup.net/ -- with hAtom 0.1 (and hCard) support.

My updated comments below reflect the current extraction of the hAtom  
content at:

<http://chunkysoup.net/extras/behindcs/>
<http://www.lukearno.com/projects/hatom2atom/? 
url=http%3A%2F%2Fchunkysoup.net%2Fextras%2Fbehindcs%2F&ctype=text%2Fxml>
<http://feedvalidator.org/check.cgi? 
url=http%3A%2F%2Fwww.lukearno.com%2Fprojects%2Fhatom2atom%2F%3Furl%3Dhtt 
p%253A%252F%252Fchunkysoup.net%252Fextras%252Fbehindcs%252F%26ctype%3Dte 
xt%252Fxml>

> Chris Casciano wrote:
>> In Example 1:
>>
>> Error 1: Field Feed-updated is an empty tag -- TOOL error
> (see below)
>
>> Error 2: Field Feed-id is an enpty tag -- TOOL error
>
>  # $source-uri is an <xsl:param> for the stylesheet
>
>  IF $hfeed-level/a:[@rel="bookmark"]
> 	FEED-ID = $feed-level/a:[@rel="bookmark"]/@href
>  ELSE IF $hfeed-element[@id != ""]
> 	FEED-ID = $source-uri + "#" + @id
>  ELSE
> 	FEED-ID = $source-uri
>
> Note: The proxy had a bug, it didn't pass $source-uri to the XSL - this
> is fixed now.

I see that.... and it seems to be working, though I now get the new  
warning:

line 5, column 94: Same-document reference [help]
     ... tras/behindcs/#posts" type="text/html"/>

>
>> Warning 2: Feed Missing atom:link with rel="self" -- would be TOOL
> So what should that link look like?
> <link
>       rel="self"
>       href="http://someproxy.org/?url=http://example.com/bar" />
>

I'm not the one to answer that.

>> In Example 2:
>
>> Error 2: Field Feed- id must be a full and valid URL --  TOOL error
>> Error 3: Field entry - id must be a full and valid URL --  TOOL error
> This was caused by the bug mentioned above.
>
>> Error 4: field entry updated must be an RFC-3339 date-time --  TOOL  
>> error
> Currently we just do copy the string from the input to the output.
> Future versions will try to re-format (and add needed extra  
> specificity)
> to the input, for example:
>
>  20031213               -> 2003-12-13T18:30:00-00:00
>  2003-12-13             -> 2003-12-13T18:30:00-00:00
>  2003-12-13 18:30+01    -> 2003-12-13T18:30:00+01:00
>  2003-12-13 18:30:02+01 -> 2003-12-13T18:30:02+01:00

For reference or future testing the current version of my example page  
uses the second form.

>
>> Things the hatom
>> parser should do but isn't:
>>
>> * Value the feed - updated timestamp based off document statistics
>
> Future versions will perhaps do something like this
> 	
> 	A = array();
> 	FOR EACH $d IN $entry-updated
> 		A.add( pad-datetime($d) )
> 	FOR EACH $d IN $entry-published
> 		A.add( pad-datetime($d) )
> 	A.sort_by ( datetime-to-utc($element) )
> 	FEED-TITLE = A[0];

Is this a better direction to take then using html document statistics?  
Neither case is sound, but this doesn't allow for things like changes  
to Author, Feed ID, or other things that might sneak into an html page  
outside of individual entry data. I'm just thinking out loud here -- I  
know the opposite case can be made -- that html-page last-mod dates  
might pick up things totally unrelated to the feed being extracted.

Again Robert, thanks for the detailed explanation and shout if you want  
a had updating or proofing anything on the wiki.

-- 
[ Chris Casciano ]
[ chris at placenamehere.com ] [ http://placenamehere.com ]



More information about the microformats-discuss mailing list