On Sun, 9 Jan 2005 15:20:56 -0800, Roy T. Fielding [EMAIL PROTECTED] wrote:
For example:
feed xmlns...
head
link href=http://example.org/feed/
...
/head
entry
idhttp://example.org/entry/id
link rel=related href=http://example.org/feed; /
...
On Sun, 9 Jan 2005 16:36:04 -0800, Roy T. Fielding [EMAIL PROTECTED] wrote:
http://www.intertwingly.net/wiki/pie/PaceFeedRecursive
I like it, but seem to remember a similar proposal being rejected - anyone..?
This approach should be pretty straightforward to program against, and
what's
On 10 Jan 2005, at 4:10 am, Roy T. Fielding wrote:
On Jan 9, 2005, at 5:38 PM, Graham wrote:
-1; Conceptual masturbation.
Wow, you like it that much? It must be a really good idea, then,
since we are all just doing this to keep you stimulated.
Sarcasm and everything. Wow. Seriously, though, all
On Sunday, January 9, 2005, at 03:18 AM, Eric Scheid wrote:
sidebar: does the signature technology we use for the atom format
allow us
to state that certain child elements are not to be included in the
signature
algorithm. I'm thinking of something along the lines of the
following...
feed
Roy T. Fielding wrote:
a proposal on making the feed element recursive
Equivalent proposals have often been made in the past (sometimes by
me!). These proposals fall in the category that we've come to know as Feed
of Feeds. Each time the proposal has been made, it has been rejected. This
This is really cache management. Use e-tags, from the HTTP 1.1 spec.
Or use an HTTP cache, which would require no changes to Atom.
Going thorugh a client-side HTTP 1.1 cache would automatically take
advantage of the e-tags and other caching information in HTTP.
wunder
--On Saturday, January 08,
Ok, I give up on this task.
I have just found that when there is a rdf:Resource you can't also have
attributes. And that attributes have to be qualified.
It is a real pity.
It would be good to make a list of what we would have needed from
RDF/XML to make Atom be rdf, and then work backwards to
On Sunday, January 9, 2005, at 05:36 PM, Roy T. Fielding wrote:
I just created a starting point for a proposal on making the
feed element recursive, eliminating the need for RDF syntax,
atom:head, and a bunch of things proposed in other paces regarding
aggregators and digital signatures.
Henry, would you mind sending me a copy of the example you were trying to
work up? I took a scroll through your recent emails to see if I could figure
out which one gave you so much trouble, but I'm not sure if I'm looking at
the right materials or not.
I'm curious because you mention that when
On Mon, 10 Jan 2005 11:49:35 -0500, Bob Wyman [EMAIL PROTECTED] wrote:
Roy T. Fielding wrote:
a proposal on making the feed element recursive
The primary arguments against Feed of Feeds have been (my
apologies if I forgot some...)
Thanks Bob.
IMHO there are pretty strong
Weve made a good bit of progress on
cleaning up our PubSub Earthquake/Tsunami reporting service and would like to
ask folk on the list to take a look at the feed were generating. (Note:
This isnt publicly announced yet, so please restrict
comments to personal email or the list.)
You can
On Jan 10, 2005, at 6:54 AM, Graham wrote:
Seriously, though, all you've done is not bothered to flatten the
data at any point.
Why is that a goal? We know all of the data is in the leaves, so
flattening them is what happens when the entries are processed
depth-first.
While this may please you,
Ok, I don't know what happened to me there. I must have been overly
tired. I went to do some weigh lifting, came back and found that my
reasoning is in fact correct.
In fact if you put in the following rdf
?xml version=1.0?
atom:Entry xmlns:atom=http://purl.org/atom/#;
On 11/1/05 6:59 AM, Danny Ayers [EMAIL PROTECTED] wrote:
Ok, I don't think there is any benefit in the normal case (feed ::=
meta, (meta, content)*), but the recursive nesting method makes it
possible to convey information about relationships between feeds.
Which begs the questions:
How
I've realised another use case for atom entry documents.
I'm using del.icio.us to track certain memes. For example:
http://del.icio.us/tag/atom
http://del.icio.us/tag/rss
http://del.icio.us/tag/folksonomy
For each of those pages they offer an RSS feed. The feed's entries contain
the
I have completed (as far as I'm concerned) PaceIRI.
The proposal is simple, namely to allow IRIs wherever the spec
currently allows URIs. I have given details of what needs to be
changed in the spec for that to happen. If anything is unclear,
I'm glad to help out the editors.
As far as I remember,
At 05:59 05/01/09, Robert Sayre wrote:
http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2
If the value of type begins with text/ or ends with +xml, the
content SHOULD be local; that is to say, no src attribute should be provided.
If you want to suggest language
At 16:04 05/01/11, Martin Duerst wrote:
I have completed (as far as I'm concerned) PaceIRI.
Just to help everybody to look at it faster, here is the URI/IRI:
http://www.intertwingly.net/wiki/pie/PaceIRI
Sorry I forgot.
The proposal is simple, namely to allow IRIs wherever the spec
currently
18 matches
Mail list logo
