Ill be making a presentation on Tuesday which will
include a slide on how Atom improves on RSS. If you have any thoughts on this
subject, I would appreciate hearing them
bob wyman
* Bob Wyman [EMAIL PROTECTED] [2005-05-22 08:05]:
I'll be making a presentation on Tuesday which will include a
slide on how Atom improves on RSS. If you have any thoughts on
this subject, I would appreciate hearing them.
I think the main attractions are pretty clear:
Thoroughly specified
Off the top of my head
* Less ambiguous
* Broader solution space
* Defined extensibility model
* Defined encryption and digital signature support
* Support for additional content types and scenarios (e.g. linked
content as opposed to embedded)
Will be interested in seeing the final list
Robert Sayre wrote:
I think the last paragraph of RFC3987, section 5.1 already says that :)
http://rfc.net/rfc3987.html#s5.1.
That also says that fragment components should be excluded. Is that true
for Atom? Are we going to refer to that specification and that section
from 4.2.7.1 in a
On 5/22/05, Graham [EMAIL PROTECTED] wrote:
On 21 May 2005, at 4:23 pm, Robert Sayre wrote:
What document is impossible to express with the current syntax?
At this point, it's impossible to express anything, since several of
us are no longer sure what the meanings of atom:author and
On 22 May 2005, at 1:09 pm, Robert Sayre wrote:
No longer sure? I suggest you never will be, since the meanings of the
elements are right there in the draft, as is the cardinality. It seems
reasonable to conclude you people can't read.
No, we just read it a different way to what you do, the
Sunday, May 22, 2005, 2:08:57 AM, Tim Bray wrote:
change from a unicode combined char to single + combining
diacritic,
No.
change in paragraph 27 of an article that doesn't show up in a
summaries-only feed,
No.
Dave: In my case, and seemingly in the case of most of the tools
On 22/5/05 10:09 PM, Robert Sayre [EMAIL PROTECTED] wrote:
What document is impossible to express with the current syntax?
At this point, it's impossible to express anything, since several of
us are no longer sure what the meanings of atom:author and
atom:contributor are meant to be.
No
Robert Sayre wrote:
I think the last paragraph of RFC3987, section 5.1 already says that :)
http://rfc.net/rfc3987.html#s5.1.
That also says that fragment components should be excluded. Is that true
for Atom?
Where does is say that?
Sorry about that. I should read better before sending
Sunday, May 22, 2005, 3:36:05 AM, Tim Bray wrote:
Summary: David Powell fails to materially address any of the three
fatal flaws I pointed out in the notion of atom:modified. I remain
firmly at -1.
Tim, thanks for taking the time to make specific points discuss this
in detail, despite
* Bob Wyman [EMAIL PROTECTED] [2005-05-22 01:52-0400]
I'll be making a presentation on Tuesday which will include a slide on how
Atom improves on RSS. If you have any thoughts on this subject, I would
appreciate hearing them.
Which version of RSS? the RDF and non-RDF strands have pretty
On 5/22/05, Graham [EMAIL PROTECTED] wrote:
On 22 May 2005, at 1:09 pm, Robert Sayre wrote:
No longer sure? I suggest you never will be, since the meanings of the
elements are right there in the draft, as is the cardinality. It seems
reasonable to conclude you people can't read.
No,
I thought it would be useful to give a use-case for
PaceAllowDuplicateIdsWithModified, so that arguments about the
validity of the use-case don't get mixed up with arguments about the
mechanics of the proposal.
The scenario is that an Atom publishing server wishes to allow
publishers to
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
I believe that the alternative of using an extension is inadequate due
to these conditions. The conditions require tight coupling of the
publishing process to the archiving process, which to me suggest that
Atom is not really supporting
I am concerned that the requirement:
atom:feed elements MUST contain exactly one atom:author element,
UNLESS all of the atom:feed element's child atom:entry elements
contain an atom:author element.
...suggests that some sort of inheritance goes on, but such a
mechanism isn't obvious and
Bob Wyman wrote:
Ill be making a presentation on Tuesday which will include a slide on
how Atom improves on RSS. If you have any thoughts on this subject, I
would appreciate hearing them
Much of the following is still relevant:
http://intertwingly.net/slides/2003/xmlconf/
I'm not certain
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
I am concerned that the requirement:
atom:feed elements MUST contain exactly one atom:author element,
UNLESS all of the atom:feed element's child atom:entry elements
contain an atom:author element.
...suggests that some sort of
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
comment from Robert in there saying that inheritance needed
explaining, but I can't see where this issue was resolved.
Oops. Here's the discussion:
http://www.imc.org/atom-syntax/mail-archive/msg13793.html
Here's what the chairs said:
Sunday, May 22, 2005, 10:22:24 AM, you wrote:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of XHTML? (I
really dislike this combined construct by the way.)
You can, but you would have to embed a full XHTML document, including
html and body elements.
On May 22, 2005, at 11:47 AM, Robert Sayre wrote:
# Any element defined by this specification MAY have an xml:lang
# attribute, whose content indicates the natural language for the
# element and its children.
s/children/descendents/?
Someone speak up if there's a preference out there
This has been an experiment...
I've got lots of thoughts on why Atom is an improvement over RSS but
I am constantly amazed that people are able to continue making the claim
that Atom offers little that RSS doesn't already support. Certainly, Winer
and the Microsoft crowd make that claim
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote:
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
comment from Robert in there saying that inheritance needed
explaining, but I can't see where this issue was resolved.
Oops. Here's the discussion:
Sunday, May 22, 2005, 7:04:41 PM, Robert Sayre wrote:
Besides, no one indicated they were unhappy with that text in WG last
call or IETF last call.
Sorry, I was too busy reviewing the 23 additional Paces that were
proposed during IETF Last-Call to have time to sufficiently review the
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
We may of thought that we were finished, but it is clear that we were
not ready for Last-Call: neither the Working Group, nor the IETF had
sufficient time to review the specification because it has been in
flux with proposals.
You know,
Bob Wyman wrote:
This has been an experiment...
I've got lots of thoughts on why Atom is an improvement over RSS but
I am constantly amazed that people are able to continue making the claim
that Atom offers little that RSS doesn't already support. Certainly, Winer
and the Microsoft
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
I think that the current text is very misleading. The fact that at one
point inheritance has been condoned or suggested by previous drafts
(including the widely implemented pre-IETF public draft), but now we
have removed the suggestion, but
On 5/22/05, Sam Ruby [EMAIL PROTECTED] wrote:
...your effort to create a concise list is very much appreciated
Here's one for RSS1: the Dublin Core module required to approach
Atom's core capabilities is extremely poorly defined. It doesn't even
commit to a string literal for fields like
Sunday, May 22, 2005, 10:25:29 PM, Robert Sayre wrote:
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
I think that the current text is very misleading. The fact that at one
point inheritance has been condoned or suggested by previous drafts
(including the widely implemented pre-IETF
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
So, are you saying that we're required to explicitly reverse any
requirement present in previous drafts?
No, we're required to state the situation one way or the other. The
current draft doesn't say that author is inherited, so I assumed
On May 22, 2005, at 3:10 PM, Robert Sayre wrote:
If it is intended to be inherited, can we still add text saying that
it is inherited as an editorial change?
We can clarify and improve the draft to your heart's delight. It's
unproductively revisiting old arguments that bothers me. :)
Tim Bray wrote:
Anybody think this is anything more than an editorial change? -Tim
Not me (you'd have to tell me that inheritance applies at all, not the
other way around). But the rules must be consistent for the elements
that appear at both levels.
cheers
Bill
Tim Bray wrote:
The intent seems pretty clear; entry-level overrides source-level
overrides feed-level, but it seems like we should say that.
Anybody think this is anything more than an editorial change? -Tim
I believe that this three-level chain of inheritance has always been
what
Bill de hÓra wrote:
Tim Bray wrote:
Anybody think this is anything more than an editorial change? -Tim
Not me (you'd have to tell me that inheritance applies at all, not the
other way around). But the rules must be consistent for the elements
that appear at both levels.
Quick
On 5/22/05, Bob Wyman [EMAIL PROTECTED] wrote:
Tim Bray wrote:
The intent seems pretty clear; entry-level overrides source-level
overrides feed-level, but it seems like we should say that.
Anybody think this is anything more than an editorial change? -Tim
I believe that this
Monday, May 23, 2005, 12:20:21 AM, Bob Wyman wrote:
Tim Bray wrote:
The intent seems pretty clear; entry-level overrides source-level
overrides feed-level, but it seems like we should say that.
Anybody think this is anything more than an editorial change? -Tim
I believe that this
At 08:47 05/05/20, Eric Scheid wrote:
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 4.1.3.1 The type attribute
Can I circumvent the DIV element by using the media type of
XHTML? (I really dislike this combined construct by the way.)
I used to find it extremely horrible. Now Im not sure.
There is some symmetry
At 6:41 PM -0400 5/21/05, Robert Sayre wrote:
Discussion since you sent this email indicates that the people who
currently think they constitute the Atompub WG don't think they need
to respect any previous consensus.
s/any/some/. Agree. Sometimes people change their mind.
(s/Sometimes/Quite
At 2:11 AM -0400 5/21/05, Bob Wyman wrote:
Tim Bray directs the editors to insert the following words:
If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed document, they describe the same entry and Atom Processors
MUST treat them as such.
It is a long
At 2:30 AM -0400 5/21/05, Bob Wyman wrote:
I
think it would be both wise and appropriate to provide text in a Security
Concerns section that describes the vulnerability of systems that rely on
Atom documents to this particular attack.
That's why we have signed documents, which are described
On 5/22/05, Robert Sayre [EMAIL PROTECTED] wrote:
It seems reasonable to conclude you people can't read.
This statement was completely inappropriate. Everyone will miss
requirements when they read a draft. The fact that everyone missed
this requirement, no matter how obvious it is under
On 23/5/05 6:01 AM, David Powell [EMAIL PROTECTED] wrote:
We should add language that specifically states that the value of
atom:feed/atom:author is not a shortcut for specifying
atom:entry/atom:author - if that is what we mean.
+1 for disambiguating either way.
e.
On 5/22/05, David Powell [EMAIL PROTECTED] wrote:
We may of thought that we were finished, but it is clear that we were
not ready for Last-Call: neither the Working Group, nor the IETF had
sufficient time to review the specification because it has been in
flux with proposals.
I can't agree
On 23/5/05 8:53 AM, Tim Bray [EMAIL PROTECTED] wrote:
Yeah, I was startled just now to realize that there's nothing there
to say that the feed-level author applies to entry-level when it's
not specified at the entry level. The intent seems pretty clear;
entry-level overrides source-level
On 5/22/05, Paul Hoffman [EMAIL PROTECTED] wrote:
At 2:11 AM -0400 5/21/05, Bob Wyman wrote:
Tim Bray directs the editors to insert the following words:
If multiple atom:entry elements with the same atom:id value appear in
an Atom Feed document, they describe the same entry and Atom
* Anne van Kesteren [EMAIL PROTECTED] [2005-05-22 11:35]:
* 3.1.1.3 XHTML
I would like to see valid XHTML more clearly defined. There
are a lot of different XHTML versions I know of and some might
not include a DIV element at all... You have XHTML 1 (in three
versions), XHTML 1.1, XHTML
On May 22, 2005, at 7:04 PM, Robert Sayre wrote:
If multiple atom:entry elements with the same atom:id value
appear in
an Atom Feed document, they describe the same entry and Atom
Processors
MUST treat them as such.
It is a long standing and valued tradition in the IETF that
On May 22, 2005, at 3:13 AM, Martin Duerst wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed.
(Text not
provided, we trust the editors to figure out the correct way to say
this). Please indicate
* Tim Bray [EMAIL PROTECTED] [2005-05-23 07:00]:
Unfortunately, among those who want to change the current
setup, we do not observe consensus on the subject of what to
change them to. Near as we can tell, people want to make
atom:author plural, some want to nuke atom:contributor and
others
PaceDateModified2 deliberately doesn't prohibit this, nor does this
prevent the proposal from fulfilling its goal to provide a temporal
ordering for entry instances.
Dave: I'm pretty much +0 on PDM2, as I've mentioned previously. Your
modifications to the concept address my this will break
Can you tell me, in those unusual cases when there is difficulty
in determining which instance came last, what the heck am I supposed to do
if the users expect to always see the most recent instance?
Bob: The same thing you'd do if you had two entries with matching ids
and modified
On 23/5/05 3:22 PM, A. Pagaltzis [EMAIL PROTECTED] wrote:
Antone Roundy suggests:
+1 make atom:author plural
+1 keep atom:contributor
punt bylines to an extension
To me that sounds like the simplest thing that can possibly work,
and looks like it hits the 80/20 mark. It also requires
On 23/5/05 3:18 PM, Roger B. [EMAIL PROTECTED] wrote:
With that in mind, what are the actual benefits of atom:modified over
atom:updated? The end result will always be identical, unless I'm
missing a crucial, well-hidden point.
atom:updated is predicated on a new feature yet to be built into
53 matches
Mail list logo
