Re: Author and contributor

On 23 May 2005, at 07:22, A. Pagaltzis wrote: In <[EMAIL PROTECTED]> (), Antone Roundy suggests: • make atom:author plural • keep atom:contributor • punt bylines to an extension +1 to all I think that makes sense, especially if one th

Re: Refresher on Updated/Modified

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 buil

Re: Author and contributor

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

Re: atom:modified (was Re: Fetch me an author. Now, fetch me another author.)

> 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 mod

Re: Refresher on Updated/Modified

> 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

Re: Author and contributor

* 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 > ot

Re: Compulsory feed ID?

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

Re: multiple ids

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 St

Re: some small comments on 08

* 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,

Re: multiple ids

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 an

Re: A different question about atom:author and inheritance

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-l

Re: A different question about atom:author and inheritance

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 ag

Re: A different question about atom:author and inheritance

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.

Sorry. (was: Fetch me an author. Now, fetch me another author.)

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 scrut

Re: Close the Atompub WG? (was: PROCESS QUESTION: are we done yet?)

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 o

RE: multiple ids

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

RE: Compulsory feed ID?

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 fu

Re: some small comments on 08

* 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 I’m not sure. There is some symm

Re: Compulsory feed ID?

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

Re: A different question about atom:author and inheritance

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 tha

Re: A different question about atom:author and inheritance

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 th

Re: A different question about atom:author and inheritance

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 followup:

RE: A different question about atom:author and inheritance

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 w

Re: A different question about atom:author and inheritance

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

Re: A different question about atom:author and inheritance

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. :) Yeah,

Re: A different question about atom:author and inheritance

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

Re: A different question about atom:author and inheritance

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-I

Re: How is Atom superior to RSS?

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

Re: A different question about atom:author and inheritance

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, b

Re: How is Atom superior to RSS?

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 crowd

Re: A different question about atom:author and inheritance

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,

Re: A different question about atom:author and inheritance

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: > http://www.imc.org/atom-synta

Re: A different question about atom:author and inheritance

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 specif

RE: How is Atom superior to RSS?

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 re

Re: some small comments on 08

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 somewhe

Re: some small comments on 08

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 and elements. Als

Re: some small comments on 08

On 5/22/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > > * 2. Atom Documents > > # This includes such elements and attributes as specified by Atom > # itself, as well as those specified by extensions to Atom. > > Doesn't this also apply to HTML and XHTML content when applicable? And > to an

Re: A different question about atom:author and inheritance

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: http:

Re: A different question about atom:author and inheritance

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

Re: How is Atom superior to RSS?

Bob Wyman wrote: 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… Much of the following is still relevant: http://intertwingly.net/slides/2003/xmlconf/ I'm not certai

A different question about atom:author and inheritance

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 i

Re: I wanna go home - process questions

Eric Scheid wrote: Paul/Tim, please advise: (1) if the format spec succeeds last call, will it not sit in limbo until the other specs which it relies upon also go into last call? > ... Which specs are you talking about? > .. Best regards, Julian

Re: A sample use-case point-by-point

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

A sample use-case point-by-point

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 download

Re: Fetch me an author. Now, fetch me another author.

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.

Re: How is Atom superior to RSS?

* 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 d

Re: Refresher on Updated/Modified

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

Re: 4.2.7.1 Comparing atom:id

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 i

Re: Fetch me an author. Now, fetch me another author.

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 mean

Re: Refresher on Updated/Modified

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

Re: Fetch me an author. Now, fetch me another author.

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 o

Re: updated and modified yet again

Sunday, May 22, 2005, 3:35:16 AM, Tim Bray wrote: > I'll repeat that. The only difference is that there might be changes > not considered significant by the publisher. > So the only reason why atom:modified can ever be more useful is if > you disagree with the publisher's opinion as to what

Re: Fetch me an author. Now, fetch me another author.

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

Re: 4.2.7.1 Comparing atom:id

On 5/22/05, Anne van Kesteren <[EMAIL PROTECTED]> wrote: > 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 doe

Re: Fetch me an author. Now, fetch me another author.

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 atom:contributor are meant to be. (And no, Robe

some small comments on 08

* 2. Atom Documents # This includes such elements and attributes as specified by Atom # itself, as well as those specified by extensions to Atom. Doesn't this also apply to HTML and XHTML content when applicable? And to any type of content in atom:content? (For example, relative SVG references.

Re: 4.2.7.1 Comparing atom:id

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 fut

Re: How is Atom superior to RSS?

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 y

Re: How is Atom superior to RSS?

* 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 specif