Wednesday, August 10, 2005, 1:30:54 AM, Robert Sayre wrote:
> On 8/9/05, David Powell <[EMAIL PROTECTED]> wrote:
>>
>> Publishers should expect that relative refs used in atom:link will
>> work, but publishers should expect that relative refs used in Simple
>> Extensions will break.
> Disagree
Wednesday, August 10, 2005, 1:34:44 AM, Tim Bray wrote:
> The problem could hypothetically arise when someone extracts
> properties from the foreign markup, stuffs them in a tuple store, and
> then when the software that knows what to do with comes along and
> retrieves it and recognizes the r
This is precisely why the expires/max-age needs to operate strictly on
the entry level. The expires/max-age elements may appear on the feed
level but it actually only applies to the entries within that feed.
Going back and reading my draft, I see that I screwed up and didn't
indicate that p
--On August 10, 2005 1:56:05 PM +1000 Eric Scheid <[EMAIL PROTECTED]> wrote:
> Aside: a perfect example of what sense of 'expires' is in the I-D itself...
>
> Network Working Group
> Internet-Draft
> Expires: January 2, 2006
Especially perfect because the HTTP header does not reflec
So, you're really looking for entry-level, time-based invalidation, no?
I guess the simplest way to do this would be to dereference the link
and see if you get a 404/410; if you do, you know it's no longer good.
That's not terribly efficient, but OTOH managing metadata in multiple
places i
Dave: I think I see what you're getting at... correct me if I'm wrong.
So I decide that my aggregator is going to look for unknown Simple
Extensions in Atom feeds and display them as a table of name/value
pairs at the bottom of every entry. And during the display process,
I'm going to run a regex
On 8/10/05, David Powell <[EMAIL PROTECTED]> wrote:
> I think that it is pretty clear, but as Tim disagrees, I think that
> this is a good indication that we need clarification.
I think it's good indication that you've argued with everyone, no
matter what they say. I'm strongly opposed to adding
* James M Snell <[EMAIL PROTECTED]> [2005-08-09 07:25]:
> The second feed illustrates the two forms of the in-reply-to
> element. The dereferenceable form uses the href attribute to
> locate the entity being responded to.
I am still strongly -1 on making the ID optional. Why do you want
to do tha
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 19:35]:
> ... and it's too late to write a pace with atom:idref, and
> wording saying an atom:link must have at least either an
> atom:href attribute or an atom:idref attribute. That is, one or
> both but not neither.
I dunno if it’d be such a great i
A. Pagaltzis wrote:
* Eric Scheid <[EMAIL PROTECTED]> [2005-08-05 19:35]:
... and it's too late to write a pace with atom:idref, and
wording saying an atom:link must have at least either an
atom:href attribute or an atom:idref attribute. That is, one or
both but not neither.
I dunno
* James M Snell <[EMAIL PROTECTED]> [2005-08-11 07:20]:
> Yes it does work in the comments draft ;-) If you haven't done
> so already, take a look at the version I submitted as an I-D
> [1]. It uses @idref for the ID reference.
Yeah, but that’s @thr:idref, not @atom:idref. ;-)
Regards,
--
Arist
On 11/8/05 3:05 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> What scenario exists wherein it would be *more* desirable to
> provide *only* a dereferencable location but *not* an ID? When
> would it be *wiser* to *rely* on a pointer to a resource which is
> always in danger of voiding, irrecove
On 11/8/05 3:20 PM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> As long as producers throw in atom:[EMAIL PROTECTED]'related'] pointers
> to the source as well, that base is covered anyway.
I'd prefer to see atom:[EMAIL PROTECTED]"in-reply-to"].
Of course it's "related". All links in an entry p
The simple answer is that not everything I may want to reply too will
have an ID I can reference. Suppose that what I'm responding to is an
item in an RSS feed that does not contain a guid element? All I have to
go off of is the URL of the RSS feed or the RSS item's link element...
neither
I *really* don't want to get into a protracted debate that gets us going
back and forth between atom:[EMAIL PROTECTED]"in-reply-to"] and thr:in-reply-to
when either approach would work just as well as the other. The
thr:in-reply-to tends to make the most sense to me at this point because
of
* James M Snell <[EMAIL PROTECTED]> [2005-08-11 08:00]:
> Suppose that what I'm responding to is an item in an RSS feed
> that does not contain a guid element? All I have to go off of
> is the URL of the RSS feed or the RSS item's link element...
> neither of which are actual ID's.
Ugh.
Sigh.
16 matches
Mail list logo
