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 h
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
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
vari
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
* 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 link, and if the @h
* 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
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 m
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² fe
On Wednesday, July 13, 2005, at 12:25 AM, A. Pagaltzis wrote:
Another might be that the aggregator asks the user on
subscription whether he/she also wants to poll the comment feed,
There's an implementation detail that should be pointed out, in case it
might influence the language ultimately
On Tuesday, July 12, 2005, at 07:23 PM, A. Pagaltzis wrote:
I think what we want to say is that “aggregators consuming this
feed should consider automatically subscribing to the referenced
feed as well,”
Automating feed subscriptions isn't something that should be done too
lightly[1]. The
* 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 discu
* 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
>
* 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 @r
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.
>
* 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 f
* 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
Antone Roundy wrote:
On Tuesday, July 12, 2005, at 07:23 PM, A. Pagaltzis wrote:
I think what we want to say is that “aggregators consuming this
feed should consider automatically subscribing to the referenced
feed as well,”
Automating feed subscriptions isn't something that should be do
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
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
* James M Snell <[EMAIL PROTECTED]> [2005-07-13 02:55]:
> 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
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 hard
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
* 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
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
hi
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 (sh
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"
@href="
* 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 w
* 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:
>
> http://example.org/commentfeed";>
>
> href="http://example.com/commentsfeed.xml"; />
>
>
>
> Then
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 (w
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. […]
href="http://example.com/commen
* 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. […]
>
>
>
> http://example.com/commentsfeed.xml"; />
>
>
What I don’t like about th
While we're waiting for more feedback on the format spec, I've been
stewing over a number of extension ideas whatcha think?
The first is rather simple. It defines an expires element that can be
applied to a feed or an entry. I have described the basics @
http://www.snellspace.com/wp/?p
32 matches
Mail list logo
