Re: [uf-discuss] more hatom rambling - detection

2006-06-21 Thread Dimitri Glazkov

Chris,

How about this:

* look for hentry
* if found, traverse ancestors to see if there's an hfeed
** if found, add hfeed to list of feeds
** otherwise, add page to list of feeds, stop looking for hfeeds
* repeat

:DG

On 6/20/06, Chris Casciano [EMAIL PROTECTED] wrote:


Let me continue my hatom spec/issue rambling by piggy backing on the
recent hcard detection / class hijacking thread...

Given [1]:

the Feed element is optional and, if missing, is assumed to be the
page

What are the rules for detecting that an hatom feed exists in a page?
Like the other thread, I'm thinking less about the context of actually
parsing the document with an hatom capable parser, but more in the
detection context where you may have some other application (browser or
plugin) detecting that the feed exists and preparing to hand off the
document to another (feed reading) application.


[1] http://microformats.org/wiki/hatom#Feed

--
[ Chris Casciano ]
[ [EMAIL PROTECTED] ] [ http://placenamehere.com ]

___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss


Re: [uf-discuss] more hatom rambling - detection

2006-06-21 Thread brian suda
Having a XMDP URL declare in the head of the document would say for
certain that in this page, when you come across these values, you can
safely assume they are part of the microformat without there is not
guarantee that class=vcard means this is an hCard microformat.

Now, just having an XMDP URL in the profile does not guarantee that
microformats are present, some CMSes add the XFN profile automatically
with or without actual XFN values.

I would say that the profile can be used for Detection, in the RSS
world you simply add a link element in the head with special rel values.
The browser is not actually following that link and determining that it
is an RSS file, i could serve-up an image... the browser would say that
there is an RSS feed here, then when you suck it into the RSS Reader it
could still fail.

Going solely off of the XMDP Profile values would cause some
false-positives. Short of actually then parsing and checking the output,
THEN saying microformats were found, i'm not sure you can do full-proof
detection.

There was some discussion about auto-discovery awhile ago on the
wiki[1], that might be a good place to document/update ideas and/or take
this discussion to the Dev-List.

-brian

[1] - http://microformats.org/wiki/hcard-brainstorming#Auto-Discovery

Chris Casciano wrote:

 Let me continue my hatom spec/issue rambling by piggy backing on the
 recent hcard detection / class hijacking thread...

 Given [1]:

 the Feed element is optional and, if missing, is assumed to be the page

 What are the rules for detecting that an hatom feed exists in a page?
 Like the other thread, I'm thinking less about the context of actually
 parsing the document with an hatom capable parser, but more in the
 detection context where you may have some other application (browser
 or plugin) detecting that the feed exists and preparing to hand off
 the document to another (feed reading) application.


 [1] http://microformats.org/wiki/hatom#Feed


___
microformats-discuss mailing list
microformats-discuss@microformats.org
http://microformats.org/mailman/listinfo/microformats-discuss