On Aug 4, 2005, at 21:55, Joe Gregorio wrote:
Some sections of this specification are illustrated with fragments of
a non-normative RELAX NG Compact schema [RELAX-NG]. However, the text
of this specification provides the definition of conformance. A
complete schema appears in Appendix B.
This
DOAP is Description of a Project, done in RDF. CodeZoo are using Atom
as a format to receive project updates, using DOAP RDF/XML as a
payload.
Details -
-- Forwarded message --
From: Edd Dumbill [EMAIL PROTECTED]
Date: Aug 3, 2005 10:46 PM
Subject: [doap-interest] CodeZoo
Sorry for taking so long to reply. I have been off on a 700km cycle trip
http://blogs.sun.com/roller/page/bblfish/20050807
I don't really want to spend to much time on the top-X discussion, as
I am
a lot more interested in the feed history itself, but here are some
thoughts
anyway...
On
On 4 Aug 2005, at 06:27, Mark Nottingham wrote:
So, if I read you correctly, it sounds like you have a method
whereby a 'top20' feed wouldn't need history:prev to give the kind
of history that you're thinking of, right?
If that's the case, I'm tempted to just tweak the draft so that
--On August 9, 2005 1:07:29 PM +0200 Henry Story [EMAIL PROTECTED] wrote:
But I would really like some way to specify that the next feed document is an
archive (ie. won't change). This would make it easy for clients to know when
to stop following the links, ie, when they have cought up with
Walter Underwood wrote:
--On August 9, 2005 1:07:29 PM +0200 Henry Story [EMAIL PROTECTED] wrote:
But I would really like some way to specify that the next feed document is an
archive (ie. won't change). This would make it easy for clients to know when
to stop following the links, ie,
On 9 Aug 2005, at 18:32, Walter Underwood wrote:
--On August 9, 2005 9:28:52 AM -0700 James M Snell
[EMAIL PROTECTED] wrote:
I made some proposals for cache control info (expires and max-age).
That might work for this.
I missed these proposals. I've been giving some thought to an
Walter Underwood wrote:
--On August 9, 2005 9:28:52 AM -0700 James M Snell [EMAIL PROTECTED] wrote:
I made some proposals for cache control info (expires and max-age).
That might work for this.
I missed these proposals. I've been giving some thought to an expires / and
max-age
I've submitted the Comments thread and License extensions as Internet
Drafts. They should post in the coming few days. In the meantime, the
latest versions can be found at the locations below.
http://www.snellspace.com/public/draft-snell-atompub-feed-license-00.txt
To answer my own question
[[
Interesting... but why have a limit of one year? For archives, I
would like a limit of
forever.
]]
I found the following in the HTTP spec
[[
To mark a response as never expires, an origin server sends an
Expires date approximately one year from the time
Henry Story wrote:
Now I am wondering if the http mechanism is perhaps all that is needed
for what I want with the unchanging archives. If it is then perhaps this
could be explained in the Feed History RFC. Or are there other
reasons to
add and expires tag to the document itself?
On the
FYI...
**
Original Message
Subject: I-D ACTION:draft-saintandre-atompub-notify-03.txt
Date: Tue, 09 Aug 2005 15:50:01 -0400
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: i-d-announce@ietf.org
A New Internet-Draft is available from the on-line Internet-Drafts
I still believe that relative URIs shouldn't exist in Simple Extension
constructs [1]. I think that the lack of rationale for their being 2-3
classes of extension construct is proving to be harmful.
Prior to the introduction of Section 6, Atom pretty much said you can
include any foreign
On 09/08/2005, at 4:07 AM, Henry Story wrote:
But I would really like some way to specify that the next feed
document is an archive (ie. won't change). This would make it easy
for clients to know when to stop following the links, ie, when they
have cought up with the changes since they
On 8/9/05, David Powell [EMAIL PROTECTED] wrote:
If I'm wrong, and the rationale behind Simple Extensions isn't
important...
Sorry, I don't buy this. You're wrong, but the rationale is important. :)
What are we going to do, outlaw strings that happen to look like
relative references? If you
Tuesday, August 9, 2005, 11:22:14 PM, Robert Sayre wrote:
What are we going to do, outlaw strings that happen to look like
relative references?
No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must
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. We have no idea what people will do with this, or where they
will be
On Aug 9, 2005, at 5:11 PM, David Powell wrote:
No, we just need to warn publishers (and extension authors) that the
base URI of Simple Extension elements is not significant, and that
they must not expect it to be preserved.
Either the software understands the foreign markup, in which case
On 8/9/05, Tim Bray [EMAIL PROTECTED] wrote:
And, to whoever said relative references are fragile: Wrong. When
you have to move bales of web content around from one place to
another, and just supposing hypothetically that you have internal
links, relative references are robust, absolute URIs
Tim Bray wrote:
Sounds like implementor's-guide material to me.
1
- James
HTTP isn't a transport protocol, it's a transfer protocol; i.e., the
caching information (and other entity metadata) are *part of* the
entity, not something that's conceptually separate.
The problem with having an abstract or transport-neutral concept
of caching is that it leaves you
On 10/8/05 12:46 PM, James M Snell [EMAIL PROTECTED] wrote:
This is fairly quick and off-the-cuff, but here's an initial draft to
get the ball rolling..
http://www.snellspace.com/public/draft-snell-atompub-feed-expires.txt
Looks good, I think it does need a little bit of prose explaining
First off, let me stress that I am NOT talking about caching scenarios
here... (my use of the terms application layer and transport layer
were an unfortunate mistake on my part that only served to confuse my point)
Let's get away from the multiprotocol question for a bit (it never leads
23 matches
Mail list logo
