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
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
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
Managing Feed State was a placeholder I put in the original Atom
spec draft http://www.mnot.net/drafts/draft-nottingham-atom-
format-00.html#rfc.section.4 for just this kind of discussion. The
WG couldn't come to a consensus on a mechanism (my proposal was
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 dcterms:valid value:
start=George W. Bush; scheme=US Presidents; name=Bush II
I'm -1
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
mistaken.
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 http://www.ietf.org/internet-drafts/draft-ietf-
atompub-protocol-04.txt doesn't include anything about that link
relation; it was removed.
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.
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
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
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
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
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
|content type=application/xml
EndpointReference
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 would be
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:
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
16 matches
Mail list logo
