Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

James M Snell: I would expect anyone who uses RSS 1.0 would be more likely to use extensions that are well suited to RSS 1.0 and that anyone who uses Atom 1.0 would be more likely to use extensions that are well suited to Atom. If there is the possibility of cross-over, great, if not, that's o

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

Yeah, I've been thinking a bit about that. The only thing that was holding me back was that atom:published is optional and only appears on atom:entry. I wanted the extension to be able to work on the feed level also. That said, the spec could be updated to say that IF the published date is

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

Yeah, that kind of tears it for me; we could profile it, but I'm less than convinced that the potential reuse is worth it (esp. when it's so trivial to map age:expires into dcterms:valid). +1 to age:expires. On 09/10/2005, at 10:21 AM, Phil Ringnalda wrote: Mark Nottingham wrote: I'

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

On 10/10/05 2:02 PM, "James M Snell" <[EMAIL PROTECTED]> wrote: >> * dcterms:valid has slightly more functionality in that you get to >> specify a start date. >> > I don't necessarily want more functionality. The atom:updated date > gives us a perfectly good start date. Perhaps atom:published

Re: FYI: Advertising Web services with Atom 1.0

Would dc:conformsTo work in this case? Aleksander Slominski wrote: James M Snell wrote: Aleksander Slominski wrote: it is interesting that atom reader (in this case it seems to SharpReader) is actually rendering text content of | xmlns="http://www.w3.org/2005/08/addressing";>

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

James Holderness wrote: I'd be in favour of dcterms:valid (preferably restricted in form) for the following reasons: * I'm worried that producers of RSS 1.0 feeds would be more likely to use dcterms:valid and thus consumers would be obliged to support it anyway. I would expect anyone wh

Re: Feed History -04

I've been considering asking the Opensearch folks if they would be willing to separate their next/previous/first/last link relations out to a separate spec that could be made a working group draft. The paging functionality they offer provides a solution to paging in the protocol and are gene

Re: Feed History -04

I don't think not using the URI is a problem so long as the intent is to register the value and you make an attempt at standardization. The problems arise when folks use names when they have no intention of standardizing or registering. - James Mark Nottingham wrote: Looks like the whol

Re: Feed History -04

Looks like the whole "use URIs for non-registered values" approach has already gone by the wayside. Oh, well. Next time, it should just be URIs, period -- no shortcuts. On 09/10/2005, at 3:41 PM, James Holderness wrote: They have a note next to each saying "This value is pending IETF re

Re: Feed History -04

In case anyone is interested, the OpenSearch Response draft can be found here: http://opensearch.a9.com/spec/opensearchresponse/1.1/ The rel values they support include next, previous (not prev), start and end. They have a note next to each saying "This value is pending IETF registration".

Re: Feed History -04

On 10/9/05, Mark Nottingham <[EMAIL PROTECTED]> wrote: > > The format doesn't reference the API document any more, That's good. > and the > current API document atompub-protocol-04.txt> doesn't include anything about that link > relation; it was

Re: Feed History -04

The format doesn't reference the API document any more, and the current API document doesn't include anything about that link relation; it was removed. On 09/10/2005, at 12:02 PM, Joe Gregorio wrote: On 10/9/05,

Re: Feed History -04

On 10/9/05, Henry Story <[EMAIL PROTECTED]> wrote: > > It occurred to me that I should think a little more before speaking. > > There seems to be a history of the atom spec here: > > http://bitworking.org/projects/atom/ > > I could not find the prev link in any of the specs. So I guess I was > mis

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

Mark Nottingham wrote: I'm torn; on the one hand, dcterms is already defined, and already used in other feed formats; on the other hand, the syntax is less-than-simple. Indeed. A perfectly, utterly valid value: start=George W. Bush; scheme=US Presidents; name=Bush II I'm -1 on using Dubli

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

I'm torn; on the one hand, dcterms is already defined, and already used in other feed formats; on the other hand, the syntax is less- than-simple. So, I'm neutral on this. On 08/10/2005, at 7:37 AM, James M Snell wrote: Ok all, after looking this over in detail, I personally still have

Re: Feed History -04

"Managing Feed State" was a placeholder I put in the original Atom spec draft for just this kind of discussion. The WG couldn't come to a consensus on a mechanism (my proposal was

Re: Feed History -04

Funny you should say that. When you told me it was part of Atom 0.3 I also thought to myself that I should have checked that before posting. Technically you were correct. Version 0.3 of the syndication format doesn't mention next and prev explicitly, but it does say (in section 3.4.1) that th

Re: Feed History -04

It occurred to me that I should think a little more before speaking. There seems to be a history of the atom spec here: http://bitworking.org/projects/atom/ I could not find the prev link in any of the specs. So I guess I was mistaken. But I also always thought of prev and next as being very

Re: Feed History -04

I believe it was part of atom 0.3, and for some complex reason I never bothered trying to understand someone decided it should be moved over to the protocol side of things. Probably just because the debate was taking up too much time... So yes. 'prev' and 'next' have always been intended to b

Re: Feed History -04

Following up on the idea of using atom:link instead of fh:prev, I recently came across an old article by Mark Pilgrim on XML.com (http://www.xml.com/pub/a/2004/06/16/dive.html) in which he discusses the atom:link element and the various rel attributes it supports. He specifically brings up th

Re: Next and Previous

The feed level element should be considered to apply to the feed; the entry level element should be considered to apply to the entry. For example, if I produce an aggregated feed containing entries from multiple locations, I own the copyright on the feed, but the other authors own the copyri

Re: Straw Poll: age:expires vs. dcterms:valid (was Re: Unofficial last call on draft-snell-atompub-feed-expires-04.txt)

I'd be in favour of dcterms:valid (preferably restricted in form) for the following reasons: * I'm worried that producers of RSS 1.0 feeds would be more likely to use dcterms:valid and thus consumers would be obliged to support it anyway. * dcterms:valid has slightly more functionality in tha