On 17/7/05 2:27 PM, James M Snell [EMAIL PROTECTED] wrote:
It would make more sense to me to say that a particular type of
@rel value always expects a dereferencable URI or never expects
on. ³in-reply-to² would be in the latter category.
+1. Atom 1.0 does not require link href to be
Ugh, I was as clear as mud.
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-17 06:20]:
It would make more sense to me to say that a particular type of
@rel value always expects a dereferencable URI or never expects
on. “in-reply-to” would be in the latter category.
I can see the value in having
* Eric Scheid [EMAIL PROTECTED] [2005-07-13 17:35]:
Quick poll: how many feed readers let the user read the current
feed document without first requiring them to subscribe. That
is, present the content, along with a button subscribe to
future updates.
I’ve not seen any dedicated feed readers
A. Pagaltzis wrote:
* Eric Scheid [EMAIL PROTECTED] [2005-07-13 17:35]:
could we have @href and then also @idref ... then when we mean
to provide a dereferenceable uri we can put it in @href, and
when we want to provide an ID reference we can put it in
@idref. We can even put both into a
A significant part of my brain is screaming at me that the most logical
way to associate a license with an entry/feed is to use a link element.
After all, we are linking the entry/feed with an external resource (the
license) that is identifiable via URI. For instance, if I ommitted the
* Antone Roundy [EMAIL PROTECTED] [2005-07-13 04:20]:
If atom:link is intended to be dereferencable, then clearly,
any solution that takes a value from atom:id and puts it into
atom:link/@href has a strike against it since any feed that
uses non-dereferencable atom:ids would either have to
* Antone Roundy [EMAIL PROTECTED] [2005-07-13 07:05]:
Automating feed subscriptions isn't something that should be
done too lightly[1]. The default behavior for an aggregator
should be NOT to do this, and aggregators should give the user
the opportunity to control this feature on a
Tuesday, July 12, 2005, 12:29:58 AM, James M Snell wrote:
The third is a non-RDF adaptation of the Creative Commons RSS 1.0 Module
that uses the Atom link element and provides a machine readable license
for entries and feeds. It is described @
http://www.snellspace.com/wp/?p=184.
feed
* James M Snell [EMAIL PROTECTED] [2005-07-13 06:40]:
Maybe “companion?” I don’t know if I like that term, but it’s
the best single-word description I can think of off the top of
my head.
I think we could just as easily attach the you really should
auto-subscribe semantic to @rel=related
* A. Pagaltzis [EMAIL PROTECTED] [2005-07-13 08:11]:
Obviously, my own vote is that it’s fine as is: I see no reason
that dictates that atom:link must point to a concrete Web
resource, rather than just an abstract one – neither
conceptually/semantically nor in terms of consequences for
* David Powell [EMAIL PROTECTED] [2005-07-13 08:45]:
Because the content of atom:link is undefined, there is a risk
that some implementations, particularly Atom server
implementations accepting entries from a publishing client,
might just drop the contents of the element.
We had a discussion
On 13/7/05 4:25 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
True, but this doesn¹t detract from my argument that we need to
be able to signify a tighter relationship than just ³related.² An
aggregator might want to offer different UI for comment feeds, in
contrast to merely ³related² feeds.
On 13/7/05 5:17 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
I should clarify that I defer this to the particular relationship
type. In an atom:[EMAIL PROTECTED]'alternate'], I do absolutely expect
the @href to be dereferencable. What I don¹t see any reason for
is to mandate that @href must
* James M Snell [EMAIL PROTECTED] [2005-07-12 02:00]:
The second extension is a comments link type that allows an
entry to be associated with a separate feed containing
comments. […]
feed
entry
link rel=comments href=http://example.com/commentsfeed.xml; /
/entry
On Tuesday, July 12, 2005, at 12:42 PM, A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-07-12 02:00]:
The second extension is a comments link type that allows an
entry to be associated with a separate feed containing
comments. […]
feed
entry
link rel=comments
Great thoughts... exactly the kind of feedback I was looking for.
What you describe is actually the way we currently integrate comments
into feeds in the internal IBM blogging infrastructure: Entries and
Comments are integrated into a single feed. Currently there is no way
of associating
* Antone Roundy [EMAIL PROTECTED] [2005-07-12 21:25]:
If you're already creating an extension link type, why not
throw in an additional attribute too to help with that:
feed xmlns:comments=http://example.org/commentfeed;
entry
link rel=comments
* James M Snell [EMAIL PROTECTED] [2005-07-12 21:55]:
What you describe is actually the way we currently integrate
comments into feeds in the internal IBM blogging
infrastructure: Entries and Comments are integrated into a
single feed.
Great to know that there’s precedent for this as well
Ok, distilled from this conversation...
1. Comments can either be included directly within the feed or in a
separate feed.
2. Comment entries are distinguished by a link @rel=in-reply-to
@href={$original-entry/atom:id}
3. Comment feeds may be indicated using a link @rel=comments
James M Snell wrote:
Ok, distilled from this conversation...
1. Comments can either be included directly within the feed or in a
separate feed.
2. Comment entries are distinguished by a link @rel=in-reply-to
@href={$original-entry/atom:id}
As an atom:id is an identifier that might
James: Given that this kind of thing is pretty near-n-dear to me, I'm
quite interested. A couple observations and/or thoughts:
(1) I like this much, much better than the proposed ThreadsML mess of
years past. Simple is good.
(2) Implementation might be a hard sell, so don't get your hopes too
* James M Snell [EMAIL PROTECTED] [2005-07-12 23:20]:
1. Comments can either be included directly within the feed or in a
separate feed.
2. Comment entries are distinguished by a link @rel=in-reply-to
@href={$original-entry/atom:id}
3. Comment feeds may be indicated using a link
A. Pagaltzis wrote:
Hmm. That’s a nice thought that hadn’t occured to me. Thinking
about it, that would offer a way to solve a lot of the mess that
currently plagues the Trackback/Pingback mechanisms. You could
just ping the target weblog with a pointer to the feed which
contains the entry you
Roger B. wrote:
James: Given that this kind of thing is pretty near-n-dear to me, I'm
quite interested. A couple observations and/or thoughts:
(1) I like this much, much better than the proposed ThreadsML mess of
years past. Simple is good.
Absolutely.
(2) Implementation might be a
On Tuesday, July 12, 2005, at 06:21 PM, A. Pagaltzis wrote:
* Thomas Broyer [EMAIL PROTECTED] [2005-07-13 00:00]:
As an atom:id is an identifier that might (should?) not be
dereferenceable, atom:link is not a good choice.
There is nothing in the spec that forbids atom:link
That should be
A. Pagaltzis wrote:
@rel=related-feed ??? A bit more specific than related,
the nature of the relation is left unspecified. User agents
can choose to handle in whatever way they wish.
That doesn’t seem to confer more meaning than you can already
express by [EMAIL PROTECTED]'related'
26 matches
Mail list logo
