On 8 Feb 2005, at 12:14 am, Eric Scheid wrote:
PaceArchiveDocument
-1
this looks like a backdoor to feeds in feeds.
-1, agreed.
Graham
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
So, it is not possible for the current doc to fulfill the charter, and
this document is not ready for last call.
wunder
--On
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed documents makes an archive. I
don't see why we need atom:archive
+1. We need to at least discuss the model a bit more before agreeing to
a syntax. As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I have
been pitching, etc -- but unless we identify the general requirements
and a
On Monday, February 7, 2005, at 10:06 AM, Robert Sayre wrote:
Walter Underwood wrote:
I agree, but I would put it another way. The charter requires support
for archives, but we don't have a clear model for those. Without a
model, we can't spec syntax.
We have feed documents. A series of feed
Antone Roundy wrote:
entry
id revision=3foo:bar/a/id
...
/entry
...where @revision is a number whose only requirement is that the
number for a later revision be greater than the number for an
earlier revision, but skipping numbers is allowed.
Hmm... ok, at this point we have a point of disagreement. I see
archiving individual entries as being more important (or at least
equally important) as archiving feeds.
Example: my weblog is a collection of entries, not a collection of
feeds. The feed published by my weblog is just a
James M Snell wrote:
+1. We need to at least discuss the model a bit more before agreeing to
a syntax. As with all things, there are many different ways we can do
this -- a new top level elements, the @profile attribute Mark and I have
been pitching, etc -- but unless we identify the general
Collecting a bunch of recent discussion into one document, how about
these for a set of terms and their meanings:
* Entry: An abstract term describing a unit of content and metadata
associated with it.
* Entry Representation: A representation of a particular state of a
particular entry.
*
-1. Not core. The current text has a simple way of creating archives,
and extensions can be used to create more specialized archive formats.
--Paul Hoffman, Director
--Internet Mail Consortium
Yuck. I don't like the granularity of that at all. I can see checking
in individual entries, but not a single feed with every entry. What if
I'm just changing the value of a single title attribute? Should I have
to regenerate the entire feed and check in the entire feed just to
update the
Paul Hoffman wrote:
-1. Not core. The current text has a simple way of creating archives,
and extensions can be used to create more specialized archive formats.
-1 to the Pace. Agree in full.
Robert Sayre
On Monday, February 7, 2005, at 10:26 AM, Bob Wyman wrote:
Antone Roundy wrote:
entry
id revision=3foo:bar/a/id
...
/entry
...where @revision is a number whose only requirement is that the
number for a later revision be greater than the number for
-1 to the Pace. The current syntax sufficiently meets the 'support for
archives' charter, and extensions are possible.
-John
I think that the complexity that this proposal is proof of its failure.
If you look at a Feed document as simply a sliding window view into
the historical state of entries instead a sliding window view into the
current state of entries (though as I have shown these can overlap),`
then you have
On 7 Feb 2005, at 18:29, Antone Roundy wrote:
The latter seems likely to be supported by the WG, but the former does
not. I'd rather have an archive document type, and not repeat entries
in normal feeds.
I don't think the historical sliding window view forces you at all
to duplicate the entries
On Feb 7, 2005, at 20:04, Robert Sayre wrote:
Paul Hoffman wrote:
-1. Not core. The current text has a simple way of creating archives,
and extensions can be used to create more specialized archive
formats.
-1 to the Pace. Agree in full.
-1 to the Pace. Me three.
--
Henri Sivonen
[EMAIL
PaceArchiveDocument
-1
this looks like a backdoor to feeds in feeds.
If we adopt PaceProfile, then -1, otherwise +1. I'd also be fine with
losing the feed elements and just having archivehead /entry
/*/archive
Henry Story wrote:
On 6 Feb 2005, at 08:00, Bob Wyman wrote:
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to
try to
rush through something this major at the last moment before a pending
Last
Call.
I
http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more.
-1.
The use cases for archiving have not been well defined or well
discussed on this list. It is, I believe, inappropriate and unwise to try to
rush through something this major at the last moment before a pending Last
Call.
bob wyman
22 matches
Mail list logo
