So does that meant that it will be separated out from this Pace and
removed from the Images spec?
If so I think its basis is still pretty good but instead of link
rel=enclosure... it would read attachment
attachment should include rel, url, type, length.
url, type, and length is pretty
Tim Bray wrote:
Just to see if it uncovered any problems, I twiddled the ongoing
software to generate a format-05 atom feed. It didn't uncover any
problems that I could see. Norm's RNC schema was very valuable in
debugging, not that there were many bugs. Check it out at
On 2/2/05 11:29 PM, Sam Ruby [EMAIL PROTECTED] wrote:
http://www.tbray.org/ongoing/ongoing.atom
the xmlns and version indicate format-04.
-05 is functionally equivalent to -04 (sans errors)
e.
Julian Reschke wrote:
Tim Bray wrote:
Just to see if it uncovered any problems, I twiddled the ongoing
software to generate a format-05 atom feed. It didn't uncover any
problems that I could see. Norm's RNC schema was very valuable in
debugging, not that there were many bugs. Check it out at
Sam Ruby wrote:
Julian Reschke wrote:
Tim Bray wrote:
Just to see if it uncovered any problems, I twiddled the ongoing
software to generate a format-05 atom feed. It didn't uncover any
problems that I could see. Norm's RNC schema was very valuable in
debugging, not that there were many bugs.
On Wednesday, February 2, 2005, at 01:31 AM, Robert Sayre wrote:
Every Atom Processor should carefully consider their handling of every
type of element when processing incoming (X)HTML in Atom documents.
...and might wish to remove all unrecognized elements.
On Feb 2, 2005, at 4:29 AM, Sam Ruby wrote:
Norm's RNC schema was very valuable in debugging, not that there were
many bugs. Check it out at http://www.tbray.org/ongoing/ongoing.atom
the xmlns and version indicate format-04.
I didn't want to fiddle with Norm's RNC.
P.S. w.r.t. the version
I am +1 on having images, or what I call entry illustrations. BlogEd
has those, and they
work nicely. See http://today.java.net/jag/ or
http://bblfish.net/blog for blogs that
use them.
Notice that the top entry (the Feed itself) has an illustration too.
Which is another hint
that a Feed is a
On Feb 2, 2005, at 8:22 AM, Sam Ruby wrote:
Much to my surprise, scanning the current document, I don't see any
must ignore text.
Hey, we just accepted PaceExtendingAtom 24 hours or so back, give Rob
Mark a chance :)
Why not go one step further in generality and call the tagline the
summary? Then we will be closer
to the point I had been making in PaceEntriesAllTheWayDown2, and one
step closer to showing that
a Feed head is the same structure as an Entry. Or if you go the
Fielding way with the recursive
Joe Gregorio wrote:
On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre [EMAIL PROTECTED] wrote:
10.1 HTML and XHTML Content
Text Constructs and atom:content allow the delivery of HTML and XHTML
into a client application. Many elements are considered 'unsafe' in that
they open clients to one or more
-1. At least I don't see why there should be limitations at all on
where extensions can appear.
I am for a general must ignore rule.
On the other hand I think a much more ambitious extension spec would be
one Atom were defined by
something similar to the RELAX NG description we currently have
On Wednesday, February 2, 2005, at 09:49 AM, Henry Story wrote:
Why not go one step further in generality and call the tagline the
summary? Then we will be closer
to the point I had been making in PaceEntriesAllTheWayDown2, and one
step closer to showing that
a Feed head is the same structure
The atom:icon element's content is a URI which identifies an
image which provides iconic visual identification for a feed. The
image SHOULD have an aspect ratio of one (horizontal) to one
(vertical),
and should be suitable for presentation in small size.
Is there any reason why the aspect ratio
Antone Roundy wrote:
The atom:icon element's content is a URI which identifies an
image which provides iconic visual identification for a feed. The
image SHOULD have an aspect ratio of one (horizontal) to one (vertical),
and should be suitable for presentation in small size.
Is there any reason
On the other hand, the original plan was to publish both specs at
the same time, which I still think is a good idea.
Do we think there will be any dependencies in the other direction?
That is, when we work on the protocol, will we need to add things
to feed or entry? If there is a reasonable
On 2 Feb 2005, at 18:09, Antone Roundy wrote:
On Wednesday, February 2, 2005, at 09:49 AM, Henry Story wrote:
Why not go one step further in generality and call the tagline the
summary? Then we will be closer
to the point I had been making in PaceEntriesAllTheWayDown2, and one
step closer to
+1.
Subtitle is less obscure, and as Graham suggests could reasonably
encompass tagline. Summary isn't far away, but subtitle and tagline
are both more suggestive of the kind of half-a-sentence people use in
this position, rather than a paragraph+.
On Wed, 2 Feb 2005 15:37:09 +, Graham
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
Proposal
---
Remove atom:info and atom:host from The Atom Syndication Format.
Remove atom:host
---
No one seems to like the atom:host element. It doesn't do what its
original proponents wanted and many of
Of course things look differently if this issue affects more
platforms/parsers/toolkits.
It does. I'm in a similar boat.
On the other hand, since I'm going to be forced to parse Atom 0.3
until the end of time, and some 0.3 feeds don't use the div, it really
doesn't make a difference to me.
On Wednesday, February 2, 2005, at 11:56 AM, Walter Underwood wrote:
We are assuming that Atom will need extensions for new applications,
but it should not need extensions for editing blog entries.
I'd have to disagree. I don't think it inappropriate for elements that
exist for use by the
+1.
Subtitle is less obscure, and as Graham suggests could reasonably
encompass tagline. Summary isn't far away, but subtitle and
tagline are both more suggestive of the kind of half-a-sentence
people use in this position, rather than a paragraph+.
Relatively minor part of the spec, but I
On Wed, 2 Feb 2005 18:06:53 +0100, Henry Story [EMAIL PROTECTED] wrote:
-1. At least I don't see why there should be limitations at all on
where extensions can appear.
I am for a general must ignore rule.
On the other hand I think a much more ambitious extension spec would be
one Atom
On Tue, 01 Feb 2005 22:05:17 +0100, Julian Reschke
[EMAIL PROTECTED] wrote:
One alternative I'd like to mention is to remove all references to the
protocol spec from the document spec including the service URI
definitions, and to move the latter as extension elements into the
protocol spec.
On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote:
http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost
+1 -Tim
Walter Underwood wrote:
Hmm, I wasn't clear. While we are working on the protocol, will we
learn things that need to be applied to the format? The protocol is
an application of Atom. There will be lots of others, but this one is
core, by definition. Previous feed formats have not had an editing
--On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy [EMAIL PROTECTED] wrote:
On Wednesday, February 2, 2005, at 11:56 AM, Walter Underwood wrote:
We are assuming that Atom will need extensions for new applications,
but it should not need extensions for editing blog entries.
I'd have
On Wednesday, February 2, 2005, at 12:33 PM, Walter Underwood wrote:
--On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy
[EMAIL PROTECTED] wrote:
On Wednesday, February 2, 2005, at 11:56 AM, Walter Underwood wrote:
We are assuming that Atom will need extensions for new
[[
Also, Person Constructs, the atom:head element, and the atom:entry
element
allow the inclusion of foreign markup.
]]
If one could add foreign markup anywhere then the above sentence would
be
redundant.
Henry Story
http://bblfish.net/
On 2 Feb 2005, at 20:01, Joe Gregorio wrote:
How is
On Wed, 02 Feb 2005 10:55:06 -0800, Walter Underwood [EMAIL PROTECTED] wrote:
Or description instead of tagline. subtitle sounds like a
formatting directive to me, print this smaller and below the title.
description feels too vague.
This is one case where description and summary are not
On Feb 2, 2005, at 11:58 AM, James Snell wrote:
I'm just thinking ahead a bit on this, but I am wondering if it would
be possible for those of us interested in proposing non-core
extensions to Atom to use the Wiki as the forum for sharing proposals
for extensions once the core syntax has been
The RELAX-NG in draft-05 seems to allow atom:feed to contain
anyElement - this doesn't seem to be allowed by the spec's prose - is
this a typo?
--
Dave
On Tuesday, February 1, 2005, at 01:05 PM, Antone Roundy wrote:
-2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and
atom:content
Potentially unlimited recursion, and potentially significantly more
connections required to get a feed. This may not be a big deal to
applications
James Snell wrote:
On Wed, 02 Feb 2005 15:18:46 -0800, Tim Bray [EMAIL PROTECTED] wrote:
On Feb 2, 2005, at 11:58 AM, James Snell wrote:
I'm just thinking ahead a bit on this, but I am wondering if it would
be possible for those of us interested in proposing non-core
extensions to Atom to use the
Greetings again. And, thanks again for all the work people did on the
last work queue rotation. We now have the end of the format draft
squarely in sight.
The WG still has a bunch of finished Paces that have not been
formally considered, a (thankfully) much smaller number of unfinished
Paces,
Paul Hoffman wrote:
Please do *not* rush out to write a Pace unless it is for something that
is *truly* part of the Atom core, and you really believe that it is
likely that there will be consensus within a week.
Sorry, this is not a legitimate condition. If someone writes a Pace that
points
Sorry, I just re-read my last message and realized that I should have said
Robert and not David. I've been in a bit of a rush trying to catch up on
all of this. :)
Jeremy Gray
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Jeremy Gray
Sent: Wednesday,
A few quick comments before I transition out of the office and head towards
home:
In principle I am +1 for pretty much any spec that has the potential of
unifying entries and feeds, and feel even more strongly for those that also
unify comments and trackbacks with entries and feeds. A number of
I added the requirement for atom:aggregation to have atom:head as its
first child element. Having heard no comments on the subject of
whether or not it should be there, I thought about it a little and
decided it should.
I also decided not to do away with atom:head and move its children back
At 9:57 PM -0500 2/2/05, Robert Sayre wrote:
Paul Hoffman wrote:
Please do *not* rush out to write a Pace unless it is for something
that is *truly* part of the Atom core, and you really believe that
it is likely that there will be consensus within a week.
Sorry, this is not a legitimate
On 3/2/05 4:01 PM, Robert Sayre [EMAIL PROTECTED] wrote:
4.) Atom sucks at blogs with comments or trackbacks
5.) Atom sucks at anything with a representation of its own and
collection membership
link href=... type=application/atom+xml rel=comments /
link href=... type=application/atom+xml
http://intertwingly.net/wiki/pie/PaceCollection
== Abstract ==
Rename the top level element name for the atom document format which holds a
collection of entries, to better communicate it's collection nature, and
more easily allow non-feed collections.
== Status ==
Open
== Related and
-1. A name change of the top level element accomplishes nothing.
On Thu, 03 Feb 2005 16:55:35 +1100, Eric Scheid
[EMAIL PROTECTED] wrote:
http://intertwingly.net/wiki/pie/PaceCollection
== Abstract ==
Rename the top level element name for the atom document format which holds a
+1 Eric. sub-feeds can easily be nested by reference using the
existing link mechanism as opposed to nesting by containment. Overall
this would be a cleaner model and would be easier on bandwidth by
allowing nested feeds to be broken up over several documents rather
than stuffed all into a
Comments below..
On Thu, 03 Feb 2005 17:27:33 +1100, Eric Scheid
[EMAIL PROTECTED] wrote:
On 3/2/05 5:09 PM, James Snell [EMAIL PROTECTED] wrote:
What is the model for archiving with Atom? One or more distinct Atom
feeds that each contain a collection of old entries? If so, what we
Ok, so I'm an Atom end-user who has been monitoring the fringes of the
effort to define the spec and am now spending some time going through
the near-finished product to see what issues I can spot. That said,
likely just as most potential atom-end-users, I am not aware of the
full history of the
46 matches
Mail list logo
