Greetings again. Sam's recent work queue rotation marks what we
consider to be the likely final rotation before we are finished with
the Atom format draft. That is, the goal is that, once we accept or
close all of the items from the rotation, the format document editors
will have a complete
Sam has updated our Public Issues List, and Paul has talked about about
where we'd like to get to. I'm about to send fifteen separate
messages, one for each of the 15 (!) format-related Paces up for their
(hopefully) last go-around.
These are the result of discussion between Paul and Sam and
If there were no further discussion: This has received no -1s, but also
not a lot of wild enthusiasm. Support at the moment is a bit marginal,
but some +1s from implementors would probably make it a slam-dunk.
-Tim
If there were no further discussion: This is a radical change to the
document and, so far, hasn't gathered widespread enough support to make
it over the line. -Tim
If there were no further discussion: This topic was beaten to death a
few times in the WG. Unless there is a wave of enthusiasm unaccompanied
by -1s, the dates in the current Internet Draft will be all that ships
with the final document.
-Tim
If there were no further discussion: This is the result of a lot of
discussion around Must Ignore and has in various drafts received lots
of friendly remarks and suggestions for improvement, which have been
incorporated. Absent some convincing -1s, it probably goes in. -Tim
Tim Bray wrote:
If there were no further discussion: This topic was beaten to death a
few times in the WG. Unless there is a wave of enthusiasm unaccompanied
by -1s, the dates in the current Internet Draft will be all that ships
with the final document. -Tim
+1. I think this really is a
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like a better way to proceed than to actually
add this text to the spec.
-joe
On Mon, 24 Jan 2005 16:17:36 -0800, Tim Bray [EMAIL
Tim Bray wrote:
If there were no further discussion: This topic was beaten to death a
few times in the WG. Unless there is a wave of enthusiasm unaccompanied
by -1s, the dates in the current Internet Draft will be all that ships
with the final document.
That is, PaceDateOfSubject won't go in?
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote:
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like a better way to proceed than to actually
add this text to the spec.
Actually, take a
It's good work but it belongs in a primer or best practices document.
-joe
On Mon, 24 Jan 2005 16:17:40 -0800, Tim Bray [EMAIL PROTECTED] wrote:
If there were no further discussion: The WG completely failed to
converge to consensus on these issues last time around. Consensus can
still
+1 The alternative is that blasted feed:// URI type...
-joe
On Mon, 24 Jan 2005 16:17:44 -0800, Tim Bray [EMAIL PROTECTED] wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that
-1
If I understand all the Paces correctly, couldn't you get the same
effect by including foaf as a Structured Extension of Person?
-joe
On Mon, 24 Jan 2005 16:17:39 -0800, Tim Bray [EMAIL PROTECTED] wrote:
If there were no further discussion: Has failed to get anywhere near
enough
+1
Should there be a suggested size for images?
-joe
On Mon, 24 Jan 2005 16:18:00 -0800, Tim Bray [EMAIL PROTECTED] wrote:
If there were no further discussion: Got no -1's, seems useful, needed
for feature parity with RSS2, will likely go in absent some objections.
-Tim
--
+1 for making Atom a 'Must Ignore' language.
On Mon, 24 Jan 2005 16:17:46 -0800, Tim Bray [EMAIL PROTECTED] wrote:
If there were no further discussion: This is the result of a lot of
discussion around Must Ignore and has in various drafts received lots
of friendly remarks and suggestions
On Jan 24, 2005, at 5:12 PM, Joe Gregorio wrote:
It's good work but it belongs in a primer or best practices document.
+1. I like it, I'd like to use it somewhere, but I don't think it
belongs in the core spec. -Tim
On Jan 24, 2005, at 5:18 PM, Joe Gregorio wrote:
+1
Should there be a suggested size for images?
A suggested aspect ratio, actually. Drat. Brent Simmons loved this
idea, and I meant to update the draft. Would anyone be upset if I
updated the draft to say an aspect ratio of 2 (horizontal) to
On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray [EMAIL PROTECTED] wrote:
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote:
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like a better
On 25 Jan 2005, at 12:17 am, Tim Bray wrote:
If there were no further discussion: This topic was beaten to death a
few times in the WG. Unless there is a wave of enthusiasm
unaccompanied by -1s, the dates in the current Internet Draft will be
all that ships with the final document. -Tim
The
On 25 Jan 2005, at 12:17 am, Tim Bray wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that it adds to the base specification. -Tim
-1
Unacceptable. Language is too broad and is
-1
This approaches the problem from the wrong end. A better way to solve
it would be to list entries that weren't deleted, but expired. A more
complex solution would be to HEAD the link (or id or something) and see
if you get a 404.
Graham
On 25 Jan 2005, at 12:17 am, Tim Bray wrote:
If there
Joe Gregorio wrote:
+1 to the general Pace, but I would prefer to see
the 'Simple Extension' dropped. It adds a level of complexity
that isn't requried. and for no discernable benefit.
For example, the Pace states that A Simple Extension construct MUST
NOT have any attributes or child elements.
On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
+1 to the general Pace, but I would prefer to see
the 'Simple Extension' dropped. It adds a level of complexity
that isn't requried. and for no discernable benefit.
For example, the Pace states
On 25 Jan 2005, at 12:17 am, Tim Bray wrote:
If there were no further discussion: This is a radical change to the
document and, so far, hasn't gathered widespread enough support to
make it over the line. -Tim
-1
Architectural astronautics at its most textbook.
Graham
smime.p7s
Description:
2 questions:
1. Is there a deadline for new feature proposals? Has it passed?
There's one I want to make that depends on whether or not one in the
current round is accepted.
2. The Pace process doesn't encourage proposing minor (editorial,
style, etc) changes. It also seems to have encouraged
* Joe Gregorio [EMAIL PROTECTED] [2005-01-24 20:44-0500]
On Mon, 24 Jan 2005 20:41:40 -0500, Sam Ruby [EMAIL PROTECTED] wrote:
Joe Gregorio wrote:
+1 to the general Pace, but I would prefer to see
the 'Simple Extension' dropped. It adds a level of complexity
that isn't requried. and
On Jan 24, 2005, at 5:45 PM, Graham wrote:
1. Is there a deadline for new feature proposals? Has it passed?
There's one I want to make that depends on whether or not one in the
current round is accepted.
This being an IETF WG, you can always post a comment to a draft. If
rough consensus
On 25/1/05 12:33 PM, Graham [EMAIL PROTECTED] wrote:
BUT, making the updated date optional is something I support. Anyone
else?
I originally thought so, but was willing to bend to the will of the
developers that didn't like having an element that may or may not be there
and thus required some
On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base specification. -Tim
+1 for this pace - the tangible
Joe Gregorio wrote:
On Mon, 24 Jan 2005 17:08:45 -0800, Tim Bray [EMAIL PROTECTED] wrote:
On Jan 24, 2005, at 5:02 PM, Joe Gregorio wrote:
It reads like more of a guideline than a Pace. Inspecting the format
for conformance to these guidelines and generating Paces for
non-conformances seems like
7.2 Common element usage
The following actual elements should only be used in the ways
specified below.
* link: Purposes of link elements are specified by a list of legal
values for link/@rel, and we are considering allowing extensions to
specify additional values. If the external
At 06:38 05/01/25, Sam Ruby wrote:
Henry Story wrote:
We are all working together on the proposal, in an iterative fashion.
This is very similar to the way one develops software projects in Agile
or Extreme programming methodology. First one starts with a prototype.
One gets the major
David Powell wrote:
(I couldn't find a list of RSS2.0 extensions).
http://blogs.law.harvard.edu/tech/directory/5/specifications/rss20ModulesNamespaces
- Sam Ruby
On Monday, January 24, 2005, at 06:09 PM, Joe Gregorio wrote:
I am +1 on the //atom:head/atom:[EMAIL PROTECTED]'prev'], but -1 on
//atom:head/atom:[EMAIL PROTECTED]'wholefeed'] and -1 on any of the verbage
that makes demands on clients, for example, Atom consumers MUST warn
users when they do not
Paul Hoffman wrote:
At 1:45 AM + 1/25/05, Graham wrote:
2. The Pace process doesn't encourage proposing minor (editorial,
style, etc) changes.
Fully agree.
-05 is almost done right now. All valid -04 documents are valid -05
documents. Many editorial suggestions have been incorporated. I
On Monday, January 24, 2005, at 06:25 PM, Eric Scheid wrote:
On 25/1/05 11:17 AM, Tim Bray [EMAIL PROTECTED] wrote:
If there were no further discussion: Has failed to get anywhere near
enough support to call rough consensus in previous go-arounds. -Tim
was that failure of consensus due to
On Monday, January 24, 2005, at 05:18 PM, Tim Bray wrote:
If there were no further discussion: Got no -1's, seems useful, needed
for feature parity with RSS2, will likely go in absent some
objections. -Tim
-0.7. Turns link into a kitchen sink by using it to point to things
that are intended
* Danny Ayers wrote:
To be inserted:
{{{
Section 2. Atom Documents
Atom processors MAY interpret unprefixed attribute names as their
namespace-qualified equivalents.
If they do, then all Atom attribute names MUST appear in the Atom namespace.
}}}
This does not make much sense to me, it is
* Martin Duerst wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base specification. -Tim
+1, at least for atom:language inside the header. For elements,
39 matches
Mail list logo
