solidifying multiple hatom feed behavior

A few people recently have been asking about multiple hatom
feeds in  
a single html document, and while I know I've brought the
issue up a  
few times before we never really came to any definitive
statements  
that (a) authors could use as guidance for publishing and
(b) the  
couple of parser authors could go by to work on adding
support for  
multiple feeds.

Based in large part on this IRC conversation:
http://rbach.priv.at/Microformats-IRC/2006-05-25#T224929


I've added to the hatom issues page draft rules for
multiple feeds --  
they don't necessarily alter the 0.1 behaviors, or add any
new  
"requirements" to the spec but outline the
expected behavior in the  
various scenarios.

http://microformats.org/wiki/hatom-issue
s#Draft_Rules_for_multiple_feeds



I'd love it if anyone involved take a read through and
comment on the  
issues i've posted, or for any of the parser writers to
jump in if  
any other cases need to be outlined or the class+id issue
could be  
resolved. My goal right now is to have enough there that
someone can  
go ahead and write or modify one of the existing parsers to
handle  
multiple feeds and we can get a real world example out there
for demo  
purposes.


-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 24, 2006, at 6:38 AM, Chris Casciano wrote:

> ...
>
> I've added to the hatom issues page draft rules for
multiple feeds  
> -- they don't necessarily alter the 0.1 behaviors, or
add any new  
> "requirements" to the spec but outline the
expected behavior in the  
> various scenarios.
>
> http://microforma
ts.org/wiki/hatom- 
> issues#Draft_Rules_for_multiple_feeds


> 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?

I think we should do what browsers do - just ignore it and
work on  
the entire page.

> Issue: for authors, is there any way we can control a
redirect for  
> a feed addressed via fragment id?

With HTTP, no. With javascript, yes. Of course javascript
won't  
always work for non-visual user agents.

> 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)

I'm not quite sure what you're asking here. Can you
expound a bit?

thanks,
-ryan
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 2:53 PM, Ryan King wrote:

> On Jul 24, 2006, at 6:38 AM, Chris Casciano wrote:
>
>> ...
>>
>> I've added to the hatom issues page draft rules
for multiple feeds  
>> -- they don't necessarily alter the 0.1 behaviors,
or add any new  
>> "requirements" to the spec but outline
the expected behavior in  
>> the various scenarios.
>>
>> http://microforma
ts.org/wiki/hatom- 
>> issues#Draft_Rules_for_multiple_feeds
>
>
>> 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?
>
> I think we should do what browsers do - just ignore it
and work on  
> the entire page.
>

I'm good with that

>> Issue: for authors, is there any way we can control
a redirect for  
>> a feed addressed via fragment id?
>
> With HTTP, no. With javascript, yes. Of course
javascript won't  
> always work for non-visual user agents.
>

Its not a huge issue.. .but will come up i'm sure so I
figured I'd  
toss it out there

>> 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)
>
> I'm not quite sure what you're asking here. Can you
expound a bit?
>
> thanks,
> -ryan


If you look at the hfeed tests I posted at that link there
are a few  
potentially non-ambiguous cases where both feeds could be
explicitly  
identified.. particularly the following markup from some
document  
test.html:

<body id="feed1">
	<!-- feed 1 entries -->
	<div class="hfeed"
id="feed2">
		<!-- feed 2 entries -->
	</div>
</body>


this.html#feed2 is clear that you're addressing the inner
feed... but  
does this.html#feed1 address the outer feed only, or do you
combine  
the feed contents via SOURCE as you would this.html? [Here i
would / 
think/ you'd grab just feed1, but i could go both ways.]



I guess that brings up the general case of what to do with a
fragment  
ID when its not an hfeed element.. just parse inside the
HTML  
fragment or ignore it? e.g.

<body id="feed1">
	<!-- feed 1 entries -->
	<div class="hfeed"
id="feed2">
		<div id="notafeed">
		<!-- feed 2 entries -->
		<div>
	</div>
</body>

if the parser is passed the url test.html#notafeed do you
look only  
inside that fragment creating an almost identical feed to
#feed2, or  
ignore it and grab the whole page? [Here i'd ignore it]


-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 12:11 PM, Chris Casciano wrote:
> On Jul 25, 2006, at 2:53 PM, Ryan King wrote:
>> On Jul 24, 2006, at 6:38 AM, Chris Casciano wrote:
>>> 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)
>>
>> I'm not quite sure what you're asking here. Can
you expound a bit?
>
> If you look at the hfeed tests I posted at that link
there are a  
> few potentially non-ambiguous cases where both feeds
could be  
> explicitly identified.. particularly the following
markup from some  
> document test.html:
>
> <body id="feed1">
> 	<!-- feed 1 entries -->
> 	<div class="hfeed"
id="feed2">
> 		<!-- feed 2 entries -->
> 	</div>
> </body>
>
> this.html#feed2 is clear that you're addressing the
inner feed...  
> but does this.html#feed1 address the outer feed only,
or do you  
> combine the feed contents via SOURCE as you would
this.html? [Here  
> i would /think/ you'd grab just feed1, but i could go
both ways.]

I was under the impression that the implied-root-classname  
optimization only applies if the root classname doesn't
appear in the  
document. In other words, #feed1 is not a feed.

> I guess that brings up the general case of what to do
with a  
> fragment ID when its not an hfeed element.. just parse
inside the  
> HTML fragment or ignore it? e.g.

With X2V, we parse inside it. I think this is the most
user-friendly  
thing to do.

> <body id="feed1">
> 	<!-- feed 1 entries -->
> 	<div class="hfeed"
id="feed2">
> 		<div id="notafeed">
> 		<!-- feed 2 entries -->
> 		<div>
> 	</div>
> </body>
>
> if the parser is passed the url test.html#notafeed do
you look only  
> inside that fragment creating an almost identical feed
to #feed2,  
> or ignore it and grab the whole page? [Here i'd ignore
it]

This is a bit tricky, but I'd err on just doing what the
user says.  
If they want that part of the page, then give it to them.

-ryan
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 4:52 PM, Ryan King wrote:

> On Jul 25, 2006, at 12:11 PM, Chris Casciano wrote:
>> On Jul 25, 2006, at 2:53 PM, Ryan King wrote:
>>> On Jul 24, 2006, at 6:38 AM, Chris Casciano
wrote:
>>>> 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)
>>>
>>> I'm not quite sure what you're asking here.
Can you expound a bit?
>>
>> If you look at the hfeed tests I posted at that
link there are a  
>> few potentially non-ambiguous cases where both
feeds could be  
>> explicitly identified.. particularly the following
markup from  
>> some document test.html:
>>
>> <body id="feed1">
>> 	<!-- feed 1 entries -->
>> 	<div class="hfeed"
id="feed2">
>> 		<!-- feed 2 entries -->
>> 	</div>
>> </body>
>>
>> this.html#feed2 is clear that you're addressing
the inner feed...  
>> but does this.html#feed1 address the outer feed
only, or do you  
>> combine the feed contents via SOURCE as you would
this.html? [Here  
>> i would /think/ you'd grab just feed1, but i could
go both ways.]
>
> I was under the impression that the
implied-root-classname  
> optimization only applies if the root classname
doesn't appear in  
> the document. In other words, #feed1 is not a feed.
>

Now i'm not sure i follow...

This is 1 feed, correct?

<body>
	<!-- feed 1 entries -->
</body>


This is 1 feed, correct?

	<div class="hfeed"
id="feed2">
		<!-- feed 2 entries -->
	</div>

How does this become 1 feed and not two?

<body>
	<!-- feed 1 entries -->
	<div class="hfeed"
id="feed2">
		<!-- feed 2 entries -->
	</div>
</body>


(This is a fairly important case to me.. because it can lead
to  
instances where the content of a blog post may come along
and break  
an existing feed just by nature of its content.. and points
again to  
a de-facto requirement for class="hfeed"+id on
all feeds just to  
publish safely)


>> I guess that brings up the general case of what to
do with a  
>> fragment ID when its not an hfeed element.. just
parse inside the  
>> HTML fragment or ignore it? e.g.
>
> With X2V, we parse inside it. I think this is the most
user- 
> friendly thing to do.
>
>> <body id="feed1">
>> 	<!-- feed 1 entries -->
>> 	<div class="hfeed"
id="feed2">
>> 		<div id="notafeed">
>> 		<!-- feed 2 entries -->
>> 		<div>
>> 	</div>
>> </body>
>>
>> if the parser is passed the url test.html#notafeed
do you look  
>> only inside that fragment creating an almost
identical feed to  
>> #feed2, or ignore it and grab the whole page? [Here
i'd ignore it]
>
> This is a bit tricky, but I'd err on just doing what
the user says.  
> If they want that part of the page, then give it to
them.
>
> -ryan

I think this is pretty confusing.. and also seems to clash
with the  
need for class="hfeed" a bit

-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 3:23 PM, Chris Casciano wrote:

> How does this become 1 feed and not two?
>
> <body>
> 	<!-- feed 1 entries -->
> 	<div class="hfeed"
id="feed2">
> 		<!-- feed 2 entries -->
> 	</div>
> </body>

Per the spec []:

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

In this case, I wouldn't say that the "Feed
element" is missing. So,  
there is no full-page feed.

> (This is a fairly important case to me.. because it can
lead to  
> instances where the content of a blog post may come
along and break  
> an existing feed just by nature of its content.. and
points again  
> to a de-facto requirement for
class="hfeed"+id on all feeds just to  
> publish safely)

Haven't we defined opacity rules to deal with this problem?

-ryan
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 7:38 PM, Ryan King wrote:

> On Jul 25, 2006, at 3:23 PM, Chris Casciano wrote:
>
>> How does this become 1 feed and not two?
>>
>> <body>
>> 	<!-- feed 1 entries -->
>> 	<div class="hfeed"
id="feed2">
>> 		<!-- feed 2 entries -->
>> 	</div>
>> </body>
>
> Per the spec []:
>
>> the Feed element is optional and, if missing, is
assumed to be the  
>> page
>
> In this case, I wouldn't say that the "Feed
element" is missing.  
> So, there is no full-page feed.
>
>> (This is a fairly important case to me.. because it
can lead to  
>> instances where the content of a blog post may come
along and  
>> break an existing feed just by nature of its
content.. and points  
>> again to a de-facto requirement for
class="hfeed"+id on all feeds  
>> just to publish safely)
>
> Haven't we defined opacity rules to deal with this
problem?
>
> -ryan


You're missing my case of working with a document that
normally  
assumes a full page feed

if a page is coded for that minimal case then all could be
working  
just fine unless one of the authors of the site happens to
post a  
feed in the body of an item and then you've gone and
totally rewired  
the document as a result.

I don't see where opacity comes in here when the page wide
feed  
disappears under these circumstances...


going from this...

<body id="feed1">
	<div class="hentry"
id="post-002">
		<div class="entry-content">
			<!-- benign content -->
		</div>
	</div>
	<div class="hentry"
id="post-001">
		<div class="entry-content">
			<!-- benign content -->
		</div>
	</div>
</body>



over time to this...

<body id="feed1">
	<div class="hentry"
id="post-003">
		<div class="entry-content">
			<div class="hfeed"
id="feed2">

			</div>
		</div>
	</div>

	<div class="hentry"
id="post-002">
		<div class="entry-content">
			<!-- benign content -->
		</div>
	</div>
	<div class="hentry"
id="post-001">
		<div class="entry-content">
			<!-- benign content -->
		</div>
	</div>
</body>


If I'm understanding your reading of the spec someone could
be  
subscribing to the blog posts via page.html and have things
work as  
expected until post-003 is made and it "hijacks"
the blog feed


-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 25, 2006, at 7:14 PM, Chris Casciano wrote:

> If I'm understanding your reading of the spec someone
could be  
> subscribing to the blog posts via page.html and have
things work as  
> expected until post-003 is made and it
"hijacks" the blog feed

That's my reading also.  And when that happens, I'd think
the author  
would then realize that class="hfeed" is needed
on the body because  
the original feed doesn't always meet the criteria for an
implied  
feed.  This seems just like any other implied semantics: if
the  
implications don't reliably work for your data, use more
explicit  
markup.  class="hfeed" is only a de-facto
requirement if you can't be  
sure you won't have multiple feeds on the same page.

Peace,
Scott

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

Chris Casciano wrote:

> You're missing my case of working with a document that
normally assumes 
> a full page feed
> 
> if a page is coded for that minimal case then all could
be working just 
> fine unless one of the authors of the site happens to
post a feed in the 
> body of an item and then you've gone and totally
rewired the document as 
> a result.
> 
> I don't see where opacity comes in here when the page
wide feed 
> disappears under these circumstances...

...

> If I'm understanding your reading of the spec someone
could be 
> subscribing to the blog posts via page.html and have
things work as 
> expected until post-003 is made and it
"hijacks" the blog feed

Under what circumstances would the author of the post put a
"hfeed" into 
it? If you're thinking about quoting another blog, we've
already got 
that covered by the <blockquote> rules in entry [1].

Regards, etc...
David

[1] http://micro
formats.org/wiki/hatom#Entry
_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss

On Jul 26, 2006, at 6:58 AM, David Janes -- BlogMatrix
wrote:

> Chris Casciano wrote:
>
>> You're missing my case of working with a document
that normally  
>> assumes a full page feed
>> if a page is coded for that minimal case then all
could be working  
>> just fine unless one of the authors of the site
happens to post a  
>> feed in the body of an item and then you've gone
and totally  
>> rewired the document as a result.
>> I don't see where opacity comes in here when the
page wide feed  
>> disappears under these circumstances...
>
> ...
>
>> If I'm understanding your reading of the spec
someone could be  
>> subscribing to the blog posts via page.html and
have things work  
>> as expected until post-003 is made and it
"hijacks" the blog feed
>
> Under what circumstances would the author of the post
put a "hfeed"  
> into it? If you're thinking about quoting another
blog, we've  
> already got that covered by the <blockquote>
rules in entry [1].
>
> Regards, etc...
> David
>
> [1] http://micro
formats.org/wiki/hatom#Entry


I can think of two offhand...

- first is an example feed when talking about mfs... which i
admit  
coud be rare
- something like my versionhistory mini-feeds[1][2], though
I've used  
them on non-blog pages, might be a more common scenario for
those  
that keep similar content in blog posts[3] or forum posts
[4]

That said, I'm not sure the blockquote rule applies without
seeing  
rules for parsing order and what takes precedent... I'd
still think  
in the scenario I posted that the outer feed would never be
a  
microformat for that rule to apply.

[1] http://placenamehere.com/mf/nnwextract/#versionhistory
[2] http://placenamehere.com/mf/netnewswire/#versionhistory

[3] http://compooter.org/article/97/textpattern-pl
ugin-ajw-technorati- 
tags
[4] h
ttp://forum.textpattern.com/viewtopic.php?id=14026

-- 
[ Chris Casciano ]
[ chrisplacenamehere.com ] [ http://placenamehere.com
]

_______________________________________________
microformats-discuss mailing list
microformats-discussmicroformats.org
http://microformats.org/mailman/listinfo/microforma
ts-discuss