Henry,
The solution I eventually implemented was to include an id attribute in
the link. Clients can infer that links with the same id are actually
different views of the same resource. I know this is cheezy but I
am on a tight deadline to prototype.
BTW, I'm not sure why this did not make the
I was trying to interpret the atom:link element [1]
If I try to look at the spec in a simple relational way (what is being
related to what?)
then, given the following example atom xml extract,
entry
...
link href=http://bblfish.net/blog/page5.html#42;
type=text/html
On 25 Mar 2005, at 11:41 pm, Robert Sayre wrote:
The content of an atom:id element MUST be created in a way that
assures uniqueness; it is suggested that the atom:id element be
stored along with the associated resource.
persistence = ids must be the same each time the entry is generated
Graham wrote:
On 25 Mar 2005, at 11:41 pm, Robert Sayre wrote:
The content of an atom:id element MUST be created in a way that
assures uniqueness; it is suggested that the atom:id element be
stored along with the associated resource.
persistence = ids must be the same each time the entry
k, let's start by admitting my true goal is to get application/rss+xml
into the registered IANA media types [1]. I'm thinking this could be
done by describing the atom:link rel='self' mechanism extension to
RSS in an IETF draft, along with the required media types registration
mumbo and passing
On Mar 29, 2005, at 7:37 PM, Randy Charles Morin wrote:
k, let's start by admitting my true goal is to get application/rss+xml
into the registered IANA media types [1].
Uh, I think we can register it as a side-effect of getting the format
draft through the process with an RFC number. Right,
I tried; the official response [1] was that the IESG wanted to see an
stable and available spec -- by their standards -- for RSS before
putting it in the standards tree. Just doing a registration doesn't cut
it.
I worked on an RSS 2.0 I-D [2] for a while and then stopped when I got
it's more an issue of whether the CC Attribution + ShareAlike 1.0
license terms are satisified by the I-D boilerplate. I've just asked CC
that very question...
On Mar 29, 2005, at 10:01 PM, Robert Sayre wrote:
Mark Nottingham wrote:
I tried; the official response [1] was that the IESG wanted to
Mark Nottingham wrote:
I tried; the official response [1] was that the IESG wanted to see an
stable and available spec -- by their standards -- for RSS before
putting it in the standards tree. Just doing a registration doesn't cut
it.
I worked on an RSS 2.0 I-D [2] for a while and then
