From owner-atom-syntax@mail.imc.org Tue Feb 1 00:10:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23830 for ; Tue, 1 Feb 2005 00:10:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j114rsfj054181; Mon, 31 Jan 2005 20:53:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j114rs11054180; Mon, 31 Jan 2005 20:53:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j114rrpX054172 for ; Mon, 31 Jan 2005 20:53:53 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cvq2x-0000BH-54; Tue, 01 Feb 2005 04:53:51 +0000 Message-ID: <41FF0B5D.9060404@franklinmint.fm> Date: Mon, 31 Jan 2005 23:53:49 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Martin Duerst , Atom Syntax Subject: Re: URI canonicalization References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Over here in the thread with technical commentary, Graham wrote: > On 1 Feb 2005, at 3:10 am, Martin Duerst wrote: > >> 1) switch sections 3.5.1 and 3.5.2 to make clear that >> comparison of IDs is the most important operation. > > > Yes. I eliminated 3.5.1 as a distinct entity in this proposed edit: http://www.imc.org/atom-syntax/mail-archive/msg12807.html That got the +1 from Paul and Tim (who seemed to be on opposing sides... I don't care if we are using IRIs). None of the changes proposed below obsolete that edit. I will put it on the wiki as a "Pace" if that's what's needed. > >> This makes it clear that we are talking about "here is how >> you do it", rather than "here's one way to do it". > > > We might be treading on toes making that assertion. I can't think of anyone in this thread that would object. Esp if we are using IRIs. > >> 4) Add a sentence saying something like "Feeds or Entries >> are identical if their IDs compare identical.". >> Seems obvious, but isn't stated anywhere. > > > No. Feeds/entries with the same id are different versions or instances > of a common ancestor. They are not "the same". Martin is correct, IMHO. A URI (or GUID, for that matter) identifies *one* resource. We don't get to change that. OTOH, I don't think it will happen unless there is a commonly seen need for it to happen, so it seems like a non-issue. > >> 5) Add a note saying something like "Comparison functions >> provided by many URI classes/implementations make additional >> assumptions about equality that are not true for Identity >> Constructs. Atom processors therefore should use simple >> string functions for comparing Identity Constructs." >> I think such a note could be a good balance to the normalization >> advice. > > > Yes, though I don't like that wording. Agree. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 1 00:16:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24215 for ; Tue, 1 Feb 2005 00:16:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1152TU7055132; Mon, 31 Jan 2005 21:02:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1152SeQ055131; Mon, 31 Jan 2005 21:02:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1152S3H055125 for ; Mon, 31 Jan 2005 21:02:28 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CvqBC-0000GJ-Bo; Tue, 01 Feb 2005 05:02:22 +0000 Message-ID: <41FF0D5C.3030505@franklinmint.fm> Date: Tue, 01 Feb 2005 00:02:20 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Graham , Martin Duerst , Atom Syntax Subject: Re: URI canonicalization References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <41FF0B5D.9060404@franklinmint.fm> In-Reply-To: <41FF0B5D.9060404@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> >>> 4) Add a sentence saying something like "Feeds or Entries >>> are identical if their IDs compare identical.". >>> Seems obvious, but isn't stated anywhere. >> >> >> >> No. Feeds/entries with the same id are different versions or >> instances of a common ancestor. They are not "the same". > > > > Martin is correct, IMHO. A URI (or GUID, for that matter) identifies > *one* resource. We don't get to change that. OTOH, I don't think it > will happen unless there is a commonly seen need for it to happen, so > it seems like a non-issue. After reading Tim's response, it's obvious I totally misread this exchange. Graham is right. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 1 00:24:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24970 for ; Tue, 1 Feb 2005 00:24:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115AnAC055608; Mon, 31 Jan 2005 21:10:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j115AnZd055607; Mon, 31 Jan 2005 21:10:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115AjrE055584; Mon, 31 Jan 2005 21:10:45 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4C562519F7; Tue, 1 Feb 2005 00:10:43 -0500 (EST) In-Reply-To: References: <9d93e3488ff803c3dfd4ea9223f06352@bea.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <289792de97899fa1fd40c35230030b49@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG , Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Feed State [was: Work Queue Rotation #16] Date: Mon, 31 Jan 2005 21:10:36 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 31, 2005, at 6:27 PM, Paul Hoffman wrote: > At 3:46 PM -0800 1/31/05, Mark Nottingham wrote: >> If this is the direction we go in on this, that's fine with me, but I >> think that the spec needs to say *something* about managing feed >> state, > > Why? Because it's a *very* common use case, but we don't provide any guidance on how it's done, which IMO will lead to interoperability problems. Since the WG doesn't want to nail this down, I think it's the least we could do to point out that there may be dragons there (or at least the need for more work). > What does that add to the document? A MAY with a hint of an extension > doesn't seem to add much. Well, I tried the other way... -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Feb 1 00:34:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26212 for ; Tue, 1 Feb 2005 00:34:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115IrYR056067; Mon, 31 Jan 2005 21:18:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j115IrWf056066; Mon, 31 Jan 2005 21:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115Iq4u056051; Mon, 31 Jan 2005 21:18:52 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A5D0D51A05; Tue, 1 Feb 2005 00:18:51 -0500 (EST) In-Reply-To: <41FEEC9D.8020006@franklinmint.fm> References: <9d93e3488ff803c3dfd4ea9223f06352@bea.com> <41FEEC9D.8020006@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Paul Hoffman , Atom WG , Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Feed State [was: Work Queue Rotation #16] Date: Mon, 31 Jan 2005 21:18:44 -0800 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What registry? I don't think the examples you cite are the common case. The common case is "This Feed Document represents the last n entries in an ongoing information channel," or "This Feed Document represents entries within the last m units of time in an ongoing information channel." These cases aren't well-supported by Atom, as it stands. P.S. Feed Document may be somewhat misleading, because it's easy to confuse it with Feed (which has connotations of the information channel). I think "Feed Snapshot Document" or the like was once proposed, but it was shot down. *shrug* On Jan 31, 2005, at 6:42 PM, Robert Sayre wrote: > > Paul Hoffman wrote: > >> What does that add to the document? A MAY with a hint of an extension >> doesn't seem to add much. > > > I agree with Paul. The proposal doesn't really make sense unless > there's a way to distinguish "this feed represents the current weather > in Oaxaca" from "the latest entry represents the current weather in > Oaxaca". Also, should such a convention arise, it would be easy to add > to the registry. > > Robert Sayre > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Feb 1 00:38:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26719 for ; Tue, 1 Feb 2005 00:38:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115OiF6056503; Mon, 31 Jan 2005 21:24:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j115OiCg056502; Mon, 31 Jan 2005 21:24:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115Oh8D056496 for ; Mon, 31 Jan 2005 21:24:43 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 300054F409; Tue, 1 Feb 2005 00:24:38 -0500 (EST) Message-Id: <6.0.0.20.2.20050201134338.05f0f8c8@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 13:44:38 +0900 To: Graham From: Martin Duerst Subject: Re: URI canonicalization Cc: Atom Syntax In-Reply-To: References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 13:20 05/02/01, Graham wrote: >On 1 Feb 2005, at 3:10 am, Martin Duerst wrote: >> 4) Add a sentence saying something like "Feeds or Entries >> are identical if their IDs compare identical.". >> Seems obvious, but isn't stated anywhere. > >No. Feeds/entries with the same id are different versions or instances of a common ancestor. They are not "the same". Agreed. I'd not mind better wording (e.g. as proposed by Tim), but I think it's good to actually have something say what the fact that two IDs are the same means. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 00:43:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27223 for ; Tue, 1 Feb 2005 00:43:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115RS2b056842; Mon, 31 Jan 2005 21:27:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j115RSgo056841; Mon, 31 Jan 2005 21:27:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao05.cox.net (fed1rmmtao05.cox.net [68.230.241.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115RSDU056834 for ; Mon, 31 Jan 2005 21:27:28 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050201052721.DEYV2734.fed1rmmtao05.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 00:27:21 -0500 In-Reply-To: <6.0.0.20.2.20050201115102.06e44078@localhost> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Mon, 31 Jan 2005 21:27:05 -0800 To: Martin Duerst X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote: > 5) Add a note saying something like "Comparison functions > provided by many URI classes/implementations make additional > assumptions about equality that are not true for Identity > Constructs. Atom processors therefore should use simple > string functions for comparing Identity Constructs." > I think such a note could be a good balance to the normalization > advice. That would be a falsehood. Identifiers are not subject to "simplification" -- they are either equivalent or not. We can add all of the implementation requirements we like to prevent software from detecting false negatives, but that doesn't change the fact that equivalent identifiers always identify the same resource. It is the author's responsibility to use URIs (or IRIs) that are actually different, not the responsibility of the protocol or implementation. I am disappointed that a MUST requirement was added to IRI in the last draft without working group review. This part Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). All other applications MUST select one of the comparison practices from the Comparison Ladder (see section 5.3 or, after IRI-to-URI conversion, select one of the comparison practices from the URI comparison ladder in [RFC3986], section 6.2) is completely missing the point of the ladder. The identifiers may or may not be equivalent and there is absolutely no reason for protocols to require inaccurate comparisons. The reason for simplification of comparison is ONLY that false negatives are an acceptable fact of life and their elimination is an implementation-specific decision that has no impact on interoperable use of identifiers. That is why there is no such requirement for URIs. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 01:16:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00475 for ; Tue, 1 Feb 2005 01:16:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115v7Jt058496; Mon, 31 Jan 2005 21:57:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j115v7Lj058495; Mon, 31 Jan 2005 21:57:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j115v65P058489 for ; Mon, 31 Jan 2005 21:57:07 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050201055700.XRMY8882.fed1rmmtao06.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 00:57:00 -0500 In-Reply-To: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> References: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Mon, 31 Jan 2005 21:57:01 -0800 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit There is no reason to require any particular comparison algorithm. One application is going to compare them the same way every time. Two different applications may reach different conclusions about two equivalent identifiers, but nobody cares because AT WORST the result is a bit of inefficient use of storage. The guidance, if any, should simply state that identifier constructs must be unique. It is not our responsibility to prevent people from assigning the same (equivalent) identifiers to two different resources, nor do I care how many errors occur when they violate such a basic requirement. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 01:32:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01417 for ; Tue, 1 Feb 2005 01:32:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j116GGnU064081; Mon, 31 Jan 2005 22:16:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j116GGMR064080; Mon, 31 Jan 2005 22:16:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao08.cox.net (fed1rmmtao08.cox.net [68.230.241.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j116GFuK064046 for ; Mon, 31 Jan 2005 22:16:15 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050201061609.QMF10309.fed1rmmtao08.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 01:16:09 -0500 In-Reply-To: <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Mon, 31 Jan 2005 22:16:10 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 31, 2005, at 8:40 PM, Tim Bray wrote: > > Graham's right, the word "identical" is wrong, because in fact you > will commonly encounter two instances of the same entry which aren't > identical (e.g. the one in your cache and the one you just fetched). > I suggest "Software MUST treat any two entries which have the same ID > as instances of the same entry, regardless of how they were obtained > or any differences in their content." Or if you want it less > prescriptive "By definition, any two entries which have the same ID > are instances of the same entry, regardless of how they were obtained > or any differences in their content." Over-specification is just too fun. So that would mean I am required by Atom format to treat two different entries with the id "http://tbray.org/uid/1000" as the same entry, even when I received the first one from tbray.org and the second from mymonkeysbutt.net? Oh yeah, that'll be fun. ;-) It is not necessary for the format to require world peace, or anything generally equivalent to it. Give implementations the freedom to do whatever they like with the format -- just tell them what the syntax means and the implementations will sort themselves out. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 01:50:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02773 for ; Tue, 1 Feb 2005 01:50:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j116XISG071743; Mon, 31 Jan 2005 22:33:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j116XIMe071742; Mon, 31 Jan 2005 22:33:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j116XHMq071600 for ; Mon, 31 Jan 2005 22:33:17 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 01 Feb 2005 06:33:05 -0000 Received: from dsl-213-023-058-028.arcor-ip.net (EHLO helix) (213.23.58.28) by mail.gmx.net (mp017) with SMTP; 01 Feb 2005 07:33:05 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: "Roy T. Fielding" Cc: atom-syntax@imc.org Subject: Re: URI canonicalization Date: Tue, 01 Feb 2005 07:33:04 +0100 Message-ID: <4231226e.716048515@smtp.bjoern.hoehrmann.de> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Roy T. Fielding wrote: >It is not necessary for the format to require world peace, or >anything generally equivalent to it. Give implementations the >freedom to do whatever they like with the format -- just tell >them what the syntax means and the implementations will sort >themselves out. YMMD. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Tue Feb 1 02:11:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12574 for ; Tue, 1 Feb 2005 02:11:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j116tiqQ082348; Mon, 31 Jan 2005 22:55:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j116tiHZ082345; Mon, 31 Jan 2005 22:55:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j116tdEL082265 for ; Mon, 31 Jan 2005 22:55:39 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so1631105rne for ; Mon, 31 Jan 2005 22:55:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=YtRADRUPfi828j0ysbP9v6LNPetTBLCkKsqzBXU981ZinfQd30M7w6Am4Bn/+2GezhiLP74Ej+QYhM5TbzL2mxzqbXV6T3JvxORxswO1+DTYKn472HDI4emYiu+wVBoIbon/iaIH84mAIXMR2tFx4k2kZ2ET1Tpzl58USVcKcB0= Received: by 10.38.165.75 with SMTP id n75mr14390rne; Mon, 31 Jan 2005 22:55:31 -0800 (PST) Received: by 10.38.72.20 with HTTP; Mon, 31 Jan 2005 22:55:31 -0800 (PST) Message-ID: <2bcdc7c4050131225567ffd089@mail.gmail.com> Date: Mon, 31 Jan 2005 22:55:31 -0800 From: James Snell Reply-To: James Snell To: Peter Saint-Andre Subject: Atom Notification Protocol Update Cc: atom-syntax@imc.org, atom-protocol@imc.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2095_18273688.1107240931825" References: <2bcdc7c404121613464c0709b9@mail.gmail.com> <200412180742.CEF65051@ms8.netsolmail.com> <2bcdc7c404122311451063df01@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ------=_Part_2095_18273688.1107240931825 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 7bit I have just submitted an update to the Atom Notification Protocol draft that will hopefully be published in a day or so. I have attached the draft for review. Summary of changes: * Rather than POSTing atom:feed elements to indicate an updated feed, atom:head elements are POSTed. * Eliminated the NotificationURI location mechanisms. NotificationURI's will be located in some application specific manner. It didn't make sense at this point in time to define a common mechanism. * Head-In-Entry has been marked as a SHOULD * Expanded treatment of HTTP response codes and HTTP methods To reiterate the prior discussion that happened on this, I am not intending this as a competitor to Atom-XMPP. I think both have their place and both contribute to the General Good. I would appreciate folks giving this a look over and offering any comments you may have. -- - James Snell http://www.snellspace.com jasnell@gmail.com ------=_Part_2095_18273688.1107240931825 Content-Type: text/plain; name="draft-snell-atompub-notification-01.txt" Content-Disposition: attachment; filename="draft-snell-atompub-notification-01.txt" Content-Transfer-Encoding: quoted-printable Network Working Group J. Snell Internet-Draft January 31, 2005 Expires: August 1, 2005 The Atom Notification Protocol draft-snell-atompub-notification-01 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 1, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This memo presents a protocol for posting notifications of new or updated content using a combination of the Atom Syndication Format and HTTP POSTs. Snell Expires August 1, 2005 [Page 1] =0C Internet-Draft The Atom Notification Protocol January 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Atom Notification Protocol Model . . . . . . . . . . . . . 3 3. Functional Specification . . . . . . . . . . . . . . . . . . . 3 3.1 NotificationURI . . . . . . . . . . . . . . . . . . . . . 3 3.1.1 Locating the NotificationURI . . . . . . . . . . . . . 4 3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 6 Intellectual Property and Copyright Statements . . . . . . . . 7 Snell Expires August 1, 2005 [Page 2] =0C Internet-Draft The Atom Notification Protocol January 2005 1. Introduction The Atom Notification Protocol is an application-level protocol for posting notification of new or updated content using HTTP and the Atom Syndication Format. 1.1 Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. 1.2 Terminology Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this case, the fragment is a single 'entry' element and all its child elements. Each Atom Entry describes a single Web resource, providing metadata and optionally a textual representation of that resource. Atom Head: atom:head elements are used within the Atom Syndication Format as children of both the atom:feed and atom:entry elements to provide information descriptive of the feed. NotificationURI: A HTTP URI that is used to receive notifications about new or updated Atom entries. 2. The Atom Notification Protocol Model The Atom Notification Protocol has been designed to complement the Atom Publishing Protocol by providing the means of sending notifications when Atom-based content is modified in some way. The Atom Notification Protocol works by POSTing atom:entry or atom:head elements to a NotificationURI using HTTP POST. As is the case with the Atom Publishing Protocol, this document does not seek to specify the form of the URIs that are used. This document does, however, specify the formats of the entities posted to those URIs. 3. Functional Specification 3.1 NotificationURI The NotificationURI is used to POST notifications. A notification consists of a single atom:entry or atom:head element. The notification is essentially a one-way operation that implies no operational semantics or action on the part of the receiver. Snell Expires August 1, 2005 [Page 3] =0C Internet-Draft The Atom Notification Protocol January 2005 3.1.1 Locating the NotificationURI Because of the broad variety of cases in which the Atom Notification Protocol may be used and the lack of any single operational semantic for notifications beyond basic delivery, no single location mechanism for NotificationURI's will be defined. This means that it is up to specific application profiles to determine the best way to make the NotificationURI known within the context of that application. 3.1.2 Request The request contains a filled-in atom:entry or atom:head element. A notification request containing an atom:entry is intended to notify the receiving endpoint that a specific entry has been created or updated. A notification request containing an atom:head is intended to notify the receiving endpoint that a specific feed described by the atom:head has been created or updated. atom:entry's POSTed to a NotificationURI SHOULD contain a atom:head element that identifies the feed to which the entry belongs. atom:head elements POSTed to a NotificationURI MUST have a version attribute that identifies the Atom Syndication Format version used. The version attribute is identical to the version attribute defined for the atom:feed element in the Atom Syndication Format. Example Feed 2003-12-13T18:30:02Z John Doe POST is the only method that SHOULD be supported by the NotificationURI. Clients MUST NOT submit requests using any other method to the NotificationURI. If a client submits a request using any other method than POST, The NotificationURI SHOULD respond with a 405 Method Not Allowed response. Snell Expires August 1, 2005 [Page 4] =0C Internet-Draft The Atom Notification Protocol January 2005 3.1.3 Response The response to a notification POST MUST be an empty message. That is, the message MUST NOT contain any content beyond the HTTP headers. Clients MUST ignore any content that a NotificationURI implementation happens to include. 3.1.3.1 2xx Response Codes A response code of 202 indicates that the notification was successfully received and accepted. The body of the message SHOULD be empty. All other 2xx HTTP status codes SHOULD be treated as if they were 202 responses. 3.1.3.2 3xx Response Codes A response code of 301 indicates that the NotificationURI has permanently changed locations and that the client MUST NOT make any further attempts to send notifications to this location. A new location SHOULD be provided using the Location HTTP header field. A response code of 302 indicates that the NotificationURI has temporarily changed locations and that the client SHOULD reissue their notification to the new location specified in the Location HTTP header field but that future notifications should continue to be sent to this location. NotificationURI's SHOULD NOT return 300, 303, 304, 306 or 307 response codes. If a NotificationURI's does return any of these codes, they MUST be ignored. 3.1.3.3 4xx Response Codes All 4xx response codes are to be interpretted as they are defined in the HTTP specification. 416 and 417 SHOULD NOT be issued by the NotificationURI and MUST be ignored if they are. 3.1.3.4 5xx Response Codes All 5xx response codes are to be interpretted as they are defined in the HTTP specification. 4. Security Considerations The decision of whether or not to secure the Atom Notification Protocol will be made on a case-by-case decision. Some notification Snell Expires August 1, 2005 [Page 5] =0C Internet-Draft The Atom Notification Protocol January 2005 endpoints may be restricted to known authenticated users while others will be open for anyone who wishes to post notifications. If a given NotificationURI is restricted, the same authentication mechanism(s) used by the Atom Publishing Protocol SHOULD be used. One particular challenge that implementors of NotificationURI endpoints will need to be aware of is the potential for denial of service attacks and notification spamming. This document shall not deal with potential solutions to such attacks. 5. IANA Considerations This document has no actions for IANA. 6 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Gregorio, J., Ed. and R. Sayre, Ed., "The Atom Publishing Protocol", draft-ietf-atompub-protocol-02 (work in progress), September 2004. [3] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", draft-ietf-atompub-format-05 (work in progress), January 2005. Author's Address James M Snell EMail: james@snellspace.com URI: http://www.snellspace.com Snell Expires August 1, 2005 [Page 6] =0C Internet-Draft The Atom Notification Protocol January 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Snell Expires August 1, 2005 [Page 7] =0C ------=_Part_2095_18273688.1107240931825-- From owner-atom-syntax@mail.imc.org Tue Feb 1 04:09:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05404 for ; Tue, 1 Feb 2005 04:09:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118olP8023882; Tue, 1 Feb 2005 00:50:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j118olQl023879; Tue, 1 Feb 2005 00:50:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118ojit023725 for ; Tue, 1 Feb 2005 00:50:46 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 1 Feb 2005 21:50:55 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 01 Feb 2005 11:15:46 +1100 Subject: Re: Comments on format-05 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/2/05 6:02 AM, "Mark Nottingham" wrote: > If the concern about multiple content is solely that it will result in > more bandwidth use, I think it's misplaced; people who are concerned > about bandwidth won't publish multiple representations inline; forcing > them not to by legislation is misguided. +1 From owner-atom-syntax@mail.imc.org Tue Feb 1 04:10:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05484 for ; Tue, 1 Feb 2005 04:10:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118ol5Q023883; Tue, 1 Feb 2005 00:50:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j118olmi023881; Tue, 1 Feb 2005 00:50:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j118ojGq023712 for ; Tue, 1 Feb 2005 00:50:46 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 1 Feb 2005 21:50:53 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 01 Feb 2005 11:14:23 +1100 Subject: Re: Comments on format-05 From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/2/05 5:31 AM, "Antone Roundy" wrote: > Another option would be to allow one with inline content, and > alternative content by reference, eg. (not being careful about getting > language tags correct): +1 From owner-atom-syntax@mail.imc.org Tue Feb 1 05:08:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09460 for ; Tue, 1 Feb 2005 05:08:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119oNBs044941; Tue, 1 Feb 2005 01:50:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j119oNSG044940; Tue, 1 Feb 2005 01:50:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119oIr7044889 for ; Tue, 1 Feb 2005 01:50:18 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so29658rnz for ; Tue, 01 Feb 2005 01:50:13 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=dARrAqENJH8CYsdAlX+It+LFjH9Epx244KwrNHXqvhNeYDui6medS2lajRCVYPD21o5c5qnReUNdvKeVzvKmjjpyWxfxdzIDpXzzsVq/Ak0PpsIZ3RFktxOF34SkJmnzUMpPYohy0HTRqkr0crsAKihMaNPQOLWqfStFm9rWOvc= Received: by 10.38.8.77 with SMTP id 77mr25569rnh; Tue, 01 Feb 2005 01:50:12 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 1 Feb 2005 01:50:12 -0800 (PST) Message-ID: <1f2ed5cd050201015071587a9@mail.gmail.com> Date: Tue, 1 Feb 2005 10:50:12 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Tim Bray Subject: Re: Work Queue Rotation #16 Cc: Atom WG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Mon, 31 Jan 2005 11:45:25 -0800, Tim Bray wrote: > > Atom Public Issues List: > http://www.intertwingly.net/wiki/pie/AtomPubIssuesList Regarding PaceExtensionConstruct, PaceAttributesNamespace and Henry's RDF-related proposals, these got Catch-22'd by the process a little. The chair wanted actual spec text to enable discussion, but the text as provided (at least for PaceAttributesNamespace) was more aimed at alpha version 0.001 ballpark-finding than providing something voteworthy. I'll try and have something more workqueue-suitable for PaceAttributesNamespaces in the next few days. The other decisions look good to me - they all seem to reflect discussion accurately (although I somehow missed PaceFeedState...). Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 1 05:25:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10975 for ; Tue, 1 Feb 2005 05:25:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119ww30047280; Tue, 1 Feb 2005 01:58:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j119ww0f047279; Tue, 1 Feb 2005 01:58:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j119wqNL047250 for ; Tue, 1 Feb 2005 01:58:53 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so30154rnz for ; Tue, 01 Feb 2005 01:58:52 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=braQPHRH18TI0OaxHxM53fWykZrd8PtK3mvWx5JyOm22dtJXqa+0/zQnG5DPQW3IK1syidaOhVOH0K4fzHi4th/CzYlOnAuopgpIhKPhaJfFgGh2wZ/Pj2UK1W++YqT+QL1+zRGi77EHNrhG0izJ6nW+XxzUjzZ3FBKFiJQZ9bI= Received: by 10.38.8.7 with SMTP id 7mr137369rnh; Tue, 01 Feb 2005 01:58:52 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 1 Feb 2005 01:58:52 -0800 (PST) Message-ID: <1f2ed5cd0502010158566ea730@mail.gmail.com> Date: Tue, 1 Feb 2005 10:58:52 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Joe Gregorio Subject: Re: atom:host [was: Comments on format-05] Cc: Mark Nottingham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <3f1451f505013019516ab43262@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FD145F.3060102@franklinmint.fm> <41FD74A0.3070504@dehora.net> <27519bd7a71ca4e59919949d185c4e24@mnot.net> <3f1451f505013019516ab43262@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio wrote: > Anonymous (from IP: aaa.bbb.ccc.dddd) Well yes, and there's always: The title of this feed is "The Stuff" and the first entry it contains is titled "Hello World" from 1st February, and that has the content "... What did you end up implementing for the Wiki? I've no objection to this being dropped from the core in its current (misleading) form, I think it would probably cause more trouble than it's worth. The use case is nice and clear though - this could make an exccellent extension demo. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 1 05:26:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11034 for ; Tue, 1 Feb 2005 05:26:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11A82uX050254; Tue, 1 Feb 2005 02:08:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11A82PF050253; Tue, 1 Feb 2005 02:08:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11A81qD050214 for ; Tue, 1 Feb 2005 02:08:01 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 76331 messnum 390283 invoked from network[213.94.211.166/mail2.newbay.com]); 1 Feb 2005 10:07:54 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail05.svc.cra.dublin.eircom.net (qp 76331) with SMTP; 1 Feb 2005 10:07:54 -0000 Message-ID: <41FF54F8.8090906@dehora.net> Date: Tue, 01 Feb 2005 10:07:52 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: URI canonicalization References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: >> 4) Add a sentence saying something like "Feeds or Entries >> are identical if their IDs compare identical.". >> Seems obvious, but isn't stated anywhere. > > > No. Feeds/entries with the same id are different versions or instances > of a common ancestor. They are not "the same". +1. It is right that you shouldn't conflate two entries based on solely their ID (because they might represent different states). The main value of IDs seems to be a better user experience rather than optimized storage - but I imagine any client tool that wants to rationalize the entries presented to the reader is going to use dates heuristics as well as ids to organize what Tim is calling the entry instances. Otherwise, this thread sounds like resources and representations all over with the caveat that entry representations are being sourced from multiple origin servers. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 1 05:36:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA12131 for ; Tue, 1 Feb 2005 05:36:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11ACcnq051818; Tue, 1 Feb 2005 02:12:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11ACcLJ051817; Tue, 1 Feb 2005 02:12:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11ACbiN051780 for ; Tue, 1 Feb 2005 02:12:37 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 83461 messnum 15262161 invoked from network[213.94.211.166/mail2.newbay.com]); 1 Feb 2005 10:12:31 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail11.svc.cra.dublin.eircom.net (qp 83461) with SMTP; 1 Feb 2005 10:12:31 -0000 Message-ID: <41FF560D.7000306@dehora.net> Date: Tue, 01 Feb 2005 10:12:29 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: URI canonicalization References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > Over-specification is just too fun. So that would mean I am > required by Atom format to treat two different entries with the id > "http://tbray.org/uid/1000" > as the same entry, even when I received the first one > from tbray.org and the second from mymonkeysbutt.net? > > Oh yeah, that'll be fun. ;-) :) And yet, it's a feature of syndication to get Tim's feed entries from different origins. I already get each one from at least two sources - Planet XML, and Ongoing. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 1 06:05:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14956 for ; Tue, 1 Feb 2005 06:05:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ajhjj062942; Tue, 1 Feb 2005 02:45:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11AjhI4062940; Tue, 1 Feb 2005 02:45:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ajg1F062899 for ; Tue, 1 Feb 2005 02:45:42 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so32320rnz for ; Tue, 01 Feb 2005 02:45:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FL2AEshA8DVualuOmsBccL0xgOCLho/+x3c+AyOxr1JCKhcV5H4skRYxFPU1jzap4r954WcMbnlssbi7PTKLbgfCoYX4xvIv+s82cBdHsgS0LtutBIvFLlOo5rHkpEPsqbOi457AITVWmu66sx1CuaeYAqI3u8MP8SGrZbdyZ0M= Received: by 10.38.179.56 with SMTP id b56mr22004rnf; Tue, 01 Feb 2005 02:45:37 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 1 Feb 2005 02:45:37 -0800 (PST) Message-ID: <1f2ed5cd05020102451ec38004@mail.gmail.com> Date: Tue, 1 Feb 2005 11:45:37 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: URI canonicalization Cc: Atom Syntax In-Reply-To: <41FF54F8.8090906@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <41FF54F8.8090906@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j11Ajh1F062934 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 01 Feb 2005 10:07:52 +0000, Bill de hÓra wrote: > Otherwise, this thread sounds like resources and representations all > over with the caveat that entry representations are being sourced from > multiple origin servers. It was suggested ages ago that the use of a different URI in than the one which would usually provide representations of the entry resource might be problematic. There's an extra level of indirection between the identified entry resource and it's representations (which are in fact also representations of *other* resources). There doesn't seem to be any violation of webarch with that per se. But if we decide Cool URIs are to be considered an exception rather than the norm and use workarounds to fit with the half-baked 'permalink' practice then confusion is to be expected. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 1 06:05:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15041 for ; Tue, 1 Feb 2005 06:05:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ammtv063992; Tue, 1 Feb 2005 02:48:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11AmmeZ063991; Tue, 1 Feb 2005 02:48:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Amlob063976 for ; Tue, 1 Feb 2005 02:48:47 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 1 Feb 2005 23:49:24 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 01 Feb 2005 21:34:38 +1100 Subject: Re: Feed State [was: Work Queue Rotation #16] From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1/2/05 4:18 PM, "Mark Nottingham" wrote: > P.S. Feed Document may be somewhat misleading, because it's easy to > confuse it with Feed (which has connotations of the information > channel). I think "Feed Snapshot Document" or the like was once > proposed, but it was shot down. *shrug* "Atom Collection Document" might be even more accurate, as this also suits temporal period archives or a handpicked set of "best essays of 2004". If so, perhaps we could change the top level element name from to ? Do we need a Pace? e. From owner-atom-syntax@mail.imc.org Tue Feb 1 06:07:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15297 for ; Tue, 1 Feb 2005 06:07:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11AqGMU065246; Tue, 1 Feb 2005 02:52:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11AqGBK065245; Tue, 1 Feb 2005 02:52:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11AqF4u065183 for ; Tue, 1 Feb 2005 02:52:15 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so32626rnz for ; Tue, 01 Feb 2005 02:52:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eCNd7CF+XrVvFEi7xkY3qEMNYhbX8kwi0WhcoXVq8azpyuLa6rOU1e+hotQapv7po0PbH/6ZAw/SdKRxGKtlqnQczaMKRHd2+cSpdxFDWebHWDBofOU2dD8+/EIrBwftO/CYUBR3DWsLc4B8BuhIEw+cdA+GSogBy+Ddh1XzRP4= Received: by 10.38.8.77 with SMTP id 77mr11828rnh; Tue, 01 Feb 2005 02:52:10 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 1 Feb 2005 02:52:10 -0800 (PST) Message-ID: <1f2ed5cd05020102525050671b@mail.gmail.com> Date: Tue, 1 Feb 2005 11:52:10 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: URI canonicalization Cc: Atom Syntax In-Reply-To: <1f2ed5cd05020102451ec38004@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <41FF54F8.8090906@dehora.net> <1f2ed5cd05020102451ec38004@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nearly forgot - +1 to including some kind of explanatory note on comparisons, Martin's version looks better than the current text -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 1 07:55:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26351 for ; Tue, 1 Feb 2005 07:55:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcQsu004033; Tue, 1 Feb 2005 04:38:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11CcQ3f004032; Tue, 1 Feb 2005 04:38:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcLfb004001 for ; Tue, 1 Feb 2005 04:38:21 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id B056B4F486; Tue, 1 Feb 2005 07:38:19 -0500 (EST) Message-Id: <6.0.0.20.2.20050201145814.06fe8508@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 15:29:08 +0900 To: Robert Sayre , Graham From: Martin Duerst Subject: Re: IRIs Cc: Atom WG , Tim Bray In-Reply-To: <41FEAE1D.20201@franklinmint.fm> References: <41FE9E8C.3090109@franklinmint.fm> <85cbe7b006f977b198acbdf92f4ed25c@mac.com> <41FEAE1D.20201@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Clarifying some details based on my write-manytimes understanding of IRIs (RFC 3987). At 07:15 05/02/01, Robert Sayre wrote: > >Graham wrote: > >> I don't know much about IRIs. Is it possible to express them as URIs? > > >My read-the-draft-once understanding is that it is always possible to convert an IRI to a URI, Correct. > but it may not be possible to convert a URI back to the same IRI it was generated from. Correct. >For example, it is always possible to convert an IRI to ASCII for use in HTTP's Request-URI, but it would be better to leave it in Unicode for editing. Exactly. >There's also a large section of the draft that deals with right-to-left IRIs, but I don't understand it. It's not relevant for a protocol, but it is relevant for input and display of IRIs that contain Arabic or Hebrew characters. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 07:58:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26654 for ; Tue, 1 Feb 2005 07:58:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcZt6004111; Tue, 1 Feb 2005 04:38:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11CcZ7x004110; Tue, 1 Feb 2005 04:38:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcYES004100 for ; Tue, 1 Feb 2005 04:38:35 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6137A4F451; Tue, 1 Feb 2005 07:38:32 -0500 (EST) Message-Id: <6.0.0.20.2.20050201163925.06e0acc0@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 16:56:55 +0900 To: "Roy T. Fielding" From: Martin Duerst Subject: Re: URI canonicalization Cc: Atom Syntax In-Reply-To: <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 14:27 05/02/01, Roy T. Fielding wrote: > >On Jan 31, 2005, at 7:10 PM, Martin Duerst wrote: >> 5) Add a note saying something like "Comparison functions >> provided by many URI classes/implementations make additional >> assumptions about equality that are not true for Identity >> Constructs. Atom processors therefore should use simple >> string functions for comparing Identity Constructs." >> I think such a note could be a good balance to the normalization >> advice. > >That would be a falsehood. Identifiers are not subject to >"simplification" -- they are either equivalent or not. We can >add all of the implementation requirements we like to prevent >software from detecting false negatives, but that doesn't change >the fact that equivalent identifiers always identify the same >resource. It is the author's responsibility to use URIs >(or IRIs) that are actually different, not the responsibility >of the protocol or implementation. It's okay for some network-oriented usage to work that way. The network can fail any moment, anyway. But it's not helpful at all in some contexts that are not network-oriented. A very good case in point would be XML Namespaces. In that case, unless there is a single rule for comparison that can be used by all implementations, it would lead to some XML being declared namespace valid by one XML processor, and not namespace valid by some other XML processor. That was clearly not acceptable. >I am disappointed that a MUST requirement was added to IRI in the >last draft without working group review. This part > > Applications using IRIs as identity tokens with no relationship to a > protocol MUST use the Simple String Comparison (see section 5.3.1). > All other applications MUST select one of the comparison practices > from the Comparison Ladder (see section 5.3 or, after IRI-to-URI > conversion, select one of the comparison practices from the URI > comparison ladder in [RFC3986], section 6.2) > >is completely missing the point of the ladder. It was added due to a security review initiated by the IESG. I think I wrote the actual text, but the suggestion for the MUSTs didn't come from the authors, but from the security expert. >The identifiers may >or may not be equivalent and there is absolutely no reason for >protocols to require inaccurate comparisons. The reason for >simplification of comparison is ONLY that false negatives are >an acceptable fact of life and their elimination is an >implementation-specific decision that has no impact on >interoperable use of identifiers. That is why there is no such >requirement for URIs. The difference to the URI spec is not a good thing. But I disagree with your explanation. Both XML Namespaces and RDF (which is based on XML Namespaces) *require* character-by-character comparison, for good reasons. Otherwise, concepts such as conformance to XML Namespaces or equivalence of RDF statements would just hang in the air. Security protocols are of course another area of application where consistent behavior is extremely important. "Sometimes it may match, sometimes not" or "if you know all the schemes and protocols involved, the server used on the other side, and the intent of the creator/ maintainer of the resource for what to do about it in the future, you'll get consistent results" are just sometimes not good enough. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 07:59:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26701 for ; Tue, 1 Feb 2005 07:59:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcUUq004066; Tue, 1 Feb 2005 04:38:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11CcU2Z004065; Tue, 1 Feb 2005 04:38:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcTjR004056 for ; Tue, 1 Feb 2005 04:38:29 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 6B4854F42E; Tue, 1 Feb 2005 07:38:27 -0500 (EST) Message-Id: <6.0.0.20.2.20050201153214.06e17d00@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 16:26:01 +0900 To: DJWS , Graham , Robert Sayre From: Martin Duerst Subject: Re: IRIs (was: Re: Work Queue Rotation #16) Cc: Atom WG , Tim Bray In-Reply-To: <6.1.2.0.2.20050131232615.0555aa50@mail.datajournal.dj> References: <41FE9E8C.3090109@franklinmint.fm> <85cbe7b006f977b198acbdf92f4ed25c@mac.com> <6.1.2.0.2.20050131232615.0555aa50@mail.datajournal.dj> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 08:25 05/02/01, DJWS wrote: > >At 22:25 31/01/2005, Graham wrote: >>I don't know much about IRIs. Is it possible to express them as URIs? > >As far as I understand, and this is my problem : I cannot have a formal response on the following. >- there are various way to support a non ASCII IRI (the majority of the world needs them - inclunding French language). >- one way is to use Unicode >- another way is to use ToASCII and punycode process (used in IDNs) There is only one IRI spec (RFC 3987). For backwards compatibility, it allows the use of punycode for converting domain-name parts of some URIs. Otherwise, it's just converted to %-encoding using UTF-8, and then the URI spec (RFC 3986) takes over. >the punycode process : >- is reversible (if it was not, the Domain Name could not be valid). It is reversible up to equivalent domain names, in particular, it does not conserve case, if you take stringprep into account. >- is used in IDNs in transcoding the Unicode into ascii for 2LD and above level and in adding the prefix "xn--". There is no technical restriction to "2LD and above". There are some people claiming that it should not be used for TLDs, but I would disagree. It works for TLDs as well as for other levels. The difficult problems on the TLD level are political, but those don't go away with a different technical solution. >- can obvsiously be used to transcode the TLD of a domain name, but there is no specification in RFCs about TLDs being punycoded. I think rfc 3986 is pretty clear about this, and doesn't make an exception for TLDs. From http://www.ietf.org/rfc/rfc3986.txt: >>>>>>>> The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology. Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent- encoded to be represented as URI characters. URI producing applications must not use percent-encoding in host unless it is used to represent a UTF-8 character sequence. When a non-ASCII registered name represents an internationalized domain name intended for resolution via the DNS, the name must be transformed to the IDNA encoding [RFC3490] prior to name lookup. URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding, if they wish to maximize interoperability with legacy URI resolvers. >>>>>>>> >Yet there are "ML.ML" domain names already in use (both by Govs agencies and in private spaces). These are just rouge local setups, not conforming to any kind of spec. >I asked the author of the IRI RFC. He reponded to most of my questions. But the situation of the TLD is not clear as it is not supported by IE, but is supported by plug-in. In this sense, TLDs are no different from other levels of the domain name hierarchy. >The case of ATOM is different as not dependent from browsers. It would be a very bad idea if Atom decided to dereference URIs or IRIs in a different way from other software. >Also it is likely that in the ATOM definition timeframe the "ML.ML" (multilingual.multilingual) will most probably broadly in use in some areas of the world. It would be good. There is nothing in IRIs or URIs preventing the use of non-ASCII.non-ASCII domain names (multilingual in this context is totally inappropriate, although a lot of people use it that way). It is up to ICANN to decide on new TLDs, and it's a political problem, not a technical one. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 07:59:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26720 for ; Tue, 1 Feb 2005 07:59:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcfQY004153; Tue, 1 Feb 2005 04:38:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11Ccfsp004152; Tue, 1 Feb 2005 04:38:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CceOv004143 for ; Tue, 1 Feb 2005 04:38:40 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 5E81A4F494; Tue, 1 Feb 2005 07:38:39 -0500 (EST) Message-Id: <6.0.0.20.2.20050201180551.07481370@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 18:08:50 +0900 To: Henri Sivonen , Graham From: Martin Duerst Subject: Re: Posted PaceTextRules Cc: Atom Syntax In-Reply-To: <69A9CE97-735F-11D9-85E7-003065B8CF0E@iki.fi> References: <96392127456d5801816b3bdae724d0b2@mac.com> <69A9CE97-735F-11D9-85E7-003065B8CF0E@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 17:09 05/01/31, Henri Sivonen wrote: > >On Jan 31, 2005, at 03:00, Graham wrote: > >> "Software displaying this text SHOULD remove white-space at the beginning and end; collapse white-space between words; and disregard line break, tab and other formatting characters." in 3.1.1 (TEXT). > >+1 with the minor nit that lone line breaks should be considered spaces--not disregarded. Thus: Software displaying this text SHOULD remove white-space at the beginning and end; and treat sequences of one or more XML white-space characters as a single space. Except that that's completely inadequate for some Asian languages (Chinese, Japanese, Thai,...). Point to a spec developed by experts if you need to rather than trying to reinvent the wheel. Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 07:59:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26738 for ; Tue, 1 Feb 2005 07:59:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CciEV004186; Tue, 1 Feb 2005 04:38:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11CciXN004185; Tue, 1 Feb 2005 04:38:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CcirX004174 for ; Tue, 1 Feb 2005 04:38:44 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 5DA134F451; Tue, 1 Feb 2005 07:38:42 -0500 (EST) Message-Id: <6.0.0.20.2.20050201180913.06d6d800@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 18:09:49 +0900 To: Tim Bray , Bjoern Hoehrmann From: Martin Duerst Subject: Re: Posted PaceTextRules Cc: atom-syntax@imc.org In-Reply-To: <21DC313A-739E-11D9-9797-000A95A51C9E@sun.com> References: <96392127456d5801816b3bdae724d0b2@mac.com> <884B9E1B-7329-11D9-9797-000A95A51C9E@sun.com> <42173182.654372671@smtp.bjoern.hoehrmann.de> <21DC313A-739E-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 00:38 05/02/01, Tim Bray wrote: > > >On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote: >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different >> opinion on this matter... > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed that the W3C allowed that to be published. -Tim Would you mind explaining why you think it's wrong? Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 08:07:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27484 for ; Tue, 1 Feb 2005 08:07:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CmrB6007616; Tue, 1 Feb 2005 04:48:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11CmrJ8007614; Tue, 1 Feb 2005 04:48:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11CmpPr007600 for ; Tue, 1 Feb 2005 04:48:52 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j11CmlKj017290; Tue, 1 Feb 2005 07:48:48 -0500 (EST) Message-ID: <41FF7AB0.9060406@intertwingly.net> Date: Tue, 01 Feb 2005 07:48:48 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: atom-syntax@imc.org Subject: Re: URI canonicalization References: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> In-Reply-To: <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > There is no reason to require any particular comparison algorithm. > One application is going to compare them the same way every time. > Two different applications may reach different conclusions about > two equivalent identifiers, but nobody cares because AT WORST the > result is a bit of inefficient use of storage. It is worse than that. To give a concrete example: Radio Userland's aggregator will not present to you an item that you have seen before, no matter how different the current content is. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 1 08:19:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29537 for ; Tue, 1 Feb 2005 08:19:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11D3nHG013654; Tue, 1 Feb 2005 05:03:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11D3nRJ013653; Tue, 1 Feb 2005 05:03:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11D3lwu013614 for ; Tue, 1 Feb 2005 05:03:48 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 01 Feb 2005 13:03:42 -0000 Received: from dsl-213-023-058-028.arcor-ip.net (EHLO helix) (213.23.58.28) by mail.gmx.net (mp020) with SMTP; 01 Feb 2005 14:03:42 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Martin Duerst Cc: atom-syntax@imc.org Subject: Re: Posted PaceTextRules Date: Tue, 01 Feb 2005 14:03:41 +0100 Message-ID: <4240790e.738224562@smtp.bjoern.hoehrmann.de> References: <96392127456d5801816b3bdae724d0b2@mac.com> <884B9E1B-7329-11D9-9797-000A95A51C9E@sun.com> <42173182.654372671@smtp.bjoern.hoehrmann.de> <21DC313A-739E-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050201180913.06d6d800@localhost> In-Reply-To: <6.0.0.20.2.20050201180913.06d6d800@localhost> X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Martin Duerst wrote: > >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different > >> opinion on this matter... > > > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed > >that the W3C allowed that to be published. -Tim > >Would you mind explaining why you think it's wrong? Such white-space is considered character data in XML 1.0 and DOM Level 3 defines The Text interface inherits from CharacterData and represents the textual content (termed character data in XML) of an Element or Attr. If there is no markup inside an element's content, the text is contained in a single object implementing the Text interface that is the only child of the element. If there is markup, it is parsed into the information items (elements, comments, etc.) and Text nodes that form the list of children of the element. which refers to the XML Infoset which requires that such white-space is exposed. There is thus no reasonable ground to claim that xml:space has any impact whatsoever on the document object model; the FAQ claims the exact opposite, in particular, without ever saying what white-space would be in the DOM for e.g.

x y

It could be "x y" or "xy" or for

x y

it could be "xy", or "x y", etc. Following the cited rationale in the FAQ, all XML formats that do not define xml:space='preserve' for all elements would have essentially random white-space processing behavior, which is fortunately not the case. Please refer to   http://hades.mn.aptest.com/cgi-bin/voyager-issues/Modularization-DTDs?id=6300#followup2 for further details. -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Tue Feb 1 08:25:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00058 for ; Tue, 1 Feb 2005 08:25:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11D8oMR015562; Tue, 1 Feb 2005 05:08:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11D8orj015561; Tue, 1 Feb 2005 05:08:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11D8oWV015495 for ; Tue, 1 Feb 2005 05:08:50 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 93291 invoked by uid 17064); 1 Feb 2005 13:08:39 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2005 13:08:39 -0000 In-Reply-To: <41FF0493.7000803@franklinmint.fm> References: <13E35C6E-7408-11D9-8C3E-003065EA6144@geckotribe.com> <41FF0493.7000803@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <42205ff29bfeb8b51384a732a85d8870@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Antone Roundy , Robert Sayre From: Henry Story Subject: Principled Reasoning. was: PaceAggregationDocument posted Date: Tue, 1 Feb 2005 14:08:33 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit What is really needed here is some principled reasoning [1]. Otherwise we will be left clambering in the dark caverns of our individual prejudices. I suggest that when people make statements in favor or against something, principled reasons be given. It should be possible then to discuss the validity of the claims (are things truly the way stated), and the strength of the principles on which they rely. Perhaps it would also be useful to remember that the number of ways things can be is exceedingly large, and that often wars about what seem to be incompatible perspectives in the end turn out to be complimentary. Henry Story [1] see for example "The Nature of Rationality" by Robert Nozick http://www.amazon.com/exec/obidos/tg/detail/-/0691020965/ On 1 Feb 2005, at 05:24, Robert Sayre wrote: > Antone Roundy wrote: > >> My preferences: >> >> +1: Current draft or PaceAggregationDocument (with or without >> atom:feed/atom:head and with or without metadata for atom:aggregation >> (atom:aggregation/atom:head?)) >> +0.5: PaceFeedRecursive without any more indirection than we already >> have, and only one level of recursion >> -0.8: Real RDF >> -1: PaceFeedRecursive as it stands (no extra indirection, but >> unlimited levels of recursion) >> -1.5: "add an attribute to atom:entry that indicates whether it >> refers to an instance of entry or another feed" >> -2: PaceFeedRecursive w/ indirection at atom:feed, atom:entry, and >> atom:content > > > Cool, great to getting to know you better. > > I'd like to add the following: > > vi and Emacs suck equally. Visual Studio is surprisingly elegant when > you get to thinking about it. > > Scheme and Java suck equally. Common Lisp is surprisingly elegant when > you get to thinking about it. > > Python and Perl suck equally. Ruby is surprisingly elegant when you > get to thinking about it. > > OS X and Windows suck equally. Linux is surprisingly elegant when you > get to thinking about it. > > Robert Sayre > From owner-atom-syntax@mail.imc.org Tue Feb 1 09:46:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10287 for ; Tue, 1 Feb 2005 09:46:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11EPlf7026385; Tue, 1 Feb 2005 06:25:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11EPlJq026384; Tue, 1 Feb 2005 06:25:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11EPktZ026368 for ; Tue, 1 Feb 2005 06:25:47 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j11ENZpa003947; Tue, 1 Feb 2005 14:23:47 GMT In-Reply-To: <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-3-111597049; protocol="application/pkcs7-signature" Message-Id: <59636a550bbbfb040cdd280a4f6dc401@mac.com> Cc: Atom Syntax , Martin Duerst From: Graham Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 14:23:34 +0000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-3-111597049 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 1 Feb 2005, at 5:27 am, Roy T. Fielding wrote: > Identifiers are not subject to > "simplification" -- they are either equivalent or not. We can > add all of the implementation requirements we like to prevent > software from detecting false negatives, but that doesn't change > the fact that equivalent identifiers always identify the same > resource. It is the author's responsibility to use URIs > (or IRIs) that are actually different, not the responsibility > of the protocol or implementation. Define "equivalent" and/or "actually different" in spec text please. Good luck. Graham --Apple-Mail-3-111597049 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAxMTQyMzM1WjAjBgkqhkiG9w0BCQQxFgQUNuQ9dYxj4ZcFrSSPiugPXig0 9isweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAv9WR9G6piHe6BIj4coQr3S1M 3XP16r9HGPTHKmcY3Xk7RmBq3skaMETWdNpjFl2reZ130/hjoLd4/iIsEGfR1ufpOZhU8Vlhmi23 2oVukFiYitvte217K2zrl3IpHJaIt/BZcb38UJTCuXzNAem8BeYl9+FUIwsuuqi/e2VRTlyxKShO /GuruHw89aYGIfJ+mE78Baw/5dXziKgY61H36WUOcgTthLFQYHtuHg0eRszpS7zUzCEORjmEVRvL mVuXhO5LSlUeQ4B6Qus9eA/ZVad6krJrSn/Zg1S1rw1KoHBZj5Y7pfauTbS4+wQ47akNyorAsit4 SxiRvM2IUMqXswAAAAAAAA== --Apple-Mail-3-111597049-- From owner-atom-syntax@mail.imc.org Tue Feb 1 10:16:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14087 for ; Tue, 1 Feb 2005 10:16:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11ExHaL029146; Tue, 1 Feb 2005 06:59:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11ExHLl029145; Tue, 1 Feb 2005 06:59:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11ExFJB029130 for ; Tue, 1 Feb 2005 06:59:16 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so1730103rne for ; Tue, 01 Feb 2005 06:59:10 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eJ4eJL8cFt71K88vEfRsrm1xQo7g/fmdW/12NnL3sPXXNepeJNSwLLx/dubX1uWGNS0PDbVai9UAd8Y2BXfHzTdqSrBKY1u/ZMIFU7T/9EJ03nhIaChuTRnP6bnZ75+aUGvRijZL362tKrTwCFUGFKNDrFtWNRD60wtZ6nxcB7s= Received: by 10.38.4.61 with SMTP id 61mr202597rnd; Tue, 01 Feb 2005 06:59:10 -0800 (PST) Received: by 10.38.151.18 with HTTP; Tue, 1 Feb 2005 06:59:10 -0800 (PST) Message-ID: <3f1451f505020106591ff85081@mail.gmail.com> Date: Tue, 1 Feb 2005 09:59:10 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Danny Ayers Subject: Re: atom:host [was: Comments on format-05] Cc: Mark Nottingham , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Atom Syntax In-Reply-To: <1f2ed5cd0502010158566ea730@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FD145F.3060102@franklinmint.fm> <41FD74A0.3070504@dehora.net> <27519bd7a71ca4e59919949d185c4e24@mnot.net> <3f1451f505013019516ab43262@mail.gmail.com> <1f2ed5cd0502010158566ea730@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tue, 1 Feb 2005 10:58:52 +0100, Danny Ayers wrote: > On Sun, 30 Jan 2005 22:51:21 -0500, Joe Gregorio wrote: > > > Anonymous (from IP: aaa.bbb.ccc.dddd) > > Well yes, and there's always: > > > The title of this feed is "The Stuff" and the first entry it contains > is titled "Hello World" from 1st February, and that has the content > "... > > > What did you end up implementing for the Wiki? I punted and put myself as the author. I will probably go back and change it to use Anonymous as I outlined above. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Tue Feb 1 11:01:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19698 for ; Tue, 1 Feb 2005 11:01:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Fg02s032758; Tue, 1 Feb 2005 07:42:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11Fg0a8032757; Tue, 1 Feb 2005 07:42:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11FfxCY032750 for ; Tue, 1 Feb 2005 07:41:59 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j11Ffxdt026234 for ; Tue, 1 Feb 2005 08:41:59 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB800K1EOXY7U@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 08:41:59 -0700 (MST) Received: from [192.168.1.15] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB8000TWOXX7R@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 08:41:58 -0700 (MST) Date: Tue, 01 Feb 2005 07:42:03 -0800 From: Tim Bray Subject: Re: Posted PaceTextRules In-reply-to: <6.0.0.20.2.20050201180913.06d6d800@localhost> To: Martin Duerst Cc: Bjoern Hoehrmann , atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <96392127456d5801816b3bdae724d0b2@mac.com> <884B9E1B-7329-11D9-9797-000A95A51C9E@sun.com> <42173182.654372671@smtp.bjoern.hoehrmann.de> <21DC313A-739E-11D9-9797-000A95A51C9E@sun.com> <6.0.0.20.2.20050201180913.06d6d800@localhost> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 1, 2005, at 1:09 AM, Martin Duerst wrote: > >> http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite > different > >> opinion on this matter... > > > >Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm > amazed that the W3C allowed that to be published. -Tim > > Would you mind explaining why you think it's wrong? It says "The attribute xml:space is about input: that is to say, it controls if the spaces will be present in the DOM (i.e. in the internal version of the document inside the browser); it says nothing about what will appear on your screen." Which is wrong. xml:space is not about input whatsoever, it's a message from the provider of the document to any software downstream that cares to listen, with no normative effect. It suggests that elements which do not have "xml:space='preserve'", the DOM will necessarily remove white-space. I didn't think the DOM said that, and I just went and checked the DOM levels 1, 2, and 3 specs, and didn't find any instances of "xml:space". The DOM spec is big and complicated, maybe I missed it. But on the face of it, it seems that the text is wrong. -Tim From owner-atom-syntax@mail.imc.org Tue Feb 1 11:01:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19799 for ; Tue, 1 Feb 2005 11:01:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ffr6d032743; Tue, 1 Feb 2005 07:41:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11FfrxT032742; Tue, 1 Feb 2005 07:41:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ffqr6032725 for ; Tue, 1 Feb 2005 07:41:52 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:49488 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228698AbVBAPlg (ORCPT ); Tue, 1 Feb 2005 17:41:36 +0200 In-Reply-To: <6.0.0.20.2.20050201180551.07481370@localhost> References: <96392127456d5801816b3bdae724d0b2@mac.com> <69A9CE97-735F-11D9-85E7-003065B8CF0E@iki.fi> <6.0.0.20.2.20050201180551.07481370@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97ca6f1f758cd462a6168177bb4b4faa@iki.fi> Content-Transfer-Encoding: 7bit Cc: Graham , Atom Syntax From: Henri Sivonen Subject: Re: Posted PaceTextRules Date: Tue, 1 Feb 2005 17:41:34 +0200 To: Martin Duerst X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 11:08, Martin Duerst wrote: >> +1 with the minor nit that lone line breaks should be considered >> spaces--not disregarded. Thus: Software displaying this text SHOULD >> remove white-space at the beginning and end; and treat sequences of >> one or more XML white-space characters as a single space. > > Except that that's completely inadequate for some Asian languages > (Chinese, Japanese, Thai,...). Point to a spec developed > by experts if you need to rather than trying to reinvent the wheel. I used http://www.w3.org/TR/2004/REC-xml-20040204/#AVNormalize and the default white-space behavior of browsers as the precedent. Could you please point to a spec that is developed by experts and does not reinvent the wheel? Also, I would appreciate a pointer to a document explaining the issues with Chinese, Japanese and Thai. I don't think what I wrote above in any way precludes soft line breaks for display at places that do not have adjacent XML white-space. (All this would be so much easier if XML used linefeeds and tabs for pretty-printing and those could always be dropped and spaces were always meaningful content. Too late to change it though.) -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 1 11:02:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19839 for ; Tue, 1 Feb 2005 11:02:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11FkCq6033003; Tue, 1 Feb 2005 07:46:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11FkCe1033002; Tue, 1 Feb 2005 07:46:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11FkBEY032994 for ; Tue, 1 Feb 2005 07:46:11 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j11FkBdt000028 for ; Tue, 1 Feb 2005 08:46:11 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB8006C2P4TTK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 08:46:06 -0700 (MST) Received: from [192.168.1.15] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB8000VUP4T7R@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 08:46:05 -0700 (MST) Date: Tue, 01 Feb 2005 07:46:10 -0800 From: Tim Bray Subject: Re: URI canonicalization In-reply-to: To: "Roy T. Fielding" Cc: Atom Syntax Message-id: <65500128-7468-11D9-9797-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: > Over-specification is just too fun. So that would mean I am > required by Atom format to treat two different entries with the id > "http://tbray.org/uid/1000" > as the same entry, even when I received the first one > from tbray.org and the second from mymonkeysbutt.net? > > Oh yeah, that'll be fun. ;-) Well, it would be much better than we have now. Anyone who subscribes to aggregations (for example, I subscribe to the planetsun.org aggregated feed), is used to seeing the same entry over and over and over again. This problem is only going to get worse. With Atom's ID semantics and compulsory timestamp, I would hope that my aggregator would have a chance of not showing me the same entry unless it's got a later timestamp than what I've seen. -Tim From owner-atom-syntax@mail.imc.org Tue Feb 1 11:18:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21431 for ; Tue, 1 Feb 2005 11:18:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11G1NMa034744; Tue, 1 Feb 2005 08:01:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11G1NAw034743; Tue, 1 Feb 2005 08:01:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11G1NuB034737 for ; Tue, 1 Feb 2005 08:01:23 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 14945 invoked by uid 17064); 1 Feb 2005 16:01:23 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2005 16:01:23 -0000 In-Reply-To: <41FF7AB0.9060406@intertwingly.net> References: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> <41FF7AB0.9060406@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3224313102ae27766d07e245e6042bfb@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 17:01:15 +0100 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 Feb 2005, at 13:48, Sam Ruby wrote: > Roy T. Fielding wrote: >> There is no reason to require any particular comparison algorithm. >> One application is going to compare them the same way every time. >> Two different applications may reach different conclusions about >> two equivalent identifiers, but nobody cares because AT WORST the >> result is a bit of inefficient use of storage. > > It is worse than that. To give a concrete example: Radio Userland's > aggregator will not present to you an item that you have seen before, > no matter how different the current content is. So? They will just go out of business, as people find better aggregators or editors. Leaves a bit of space for my Open Source, BSD licenced BlogEd to make headway. Henry Story > > - Sam Ruby > From owner-atom-syntax@mail.imc.org Tue Feb 1 11:22:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21748 for ; Tue, 1 Feb 2005 11:22:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11G6tZW035131; Tue, 1 Feb 2005 08:06:55 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11G6tC6035130; Tue, 1 Feb 2005 08:06:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11G6sln035124 for ; Tue, 1 Feb 2005 08:06:54 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 25790 invoked by uid 17064); 1 Feb 2005 16:06:54 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2005 16:06:54 -0000 In-Reply-To: <65500128-7468-11D9-9797-000A95A51C9E@sun.com> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> <65500128-7468-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , Tim Bray From: Henry Story Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 17:06:48 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 1 Feb 2005, at 16:46, Tim Bray wrote: > > On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: > >> Over-specification is just too fun. So that would mean I am >> required by Atom format to treat two different entries with the id >> "http://tbray.org/uid/1000" >> as the same entry, even when I received the first one >> from tbray.org and the second from mymonkeysbutt.net? >> >> Oh yeah, that'll be fun. ;-) Yes, the id is an inverse functional property relating an Entry to a URI/IRI. It is really just as simple as that. See the Ontology at: All the rest is over specification. Henry > > Well, it would be much better than we have now. Anyone who subscribes > to aggregations (for example, I subscribe to the planetsun.org > aggregated feed), is used to seeing the same entry over and over and > over again. This problem is only going to get worse. With Atom's ID > semantics and compulsory timestamp, I would hope that my > aggregator would have a chance of not showing me the same entry unless > it's got a later timestamp than what I've seen. -Tim > From owner-atom-syntax@mail.imc.org Tue Feb 1 11:34:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22744 for ; Tue, 1 Feb 2005 11:34:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GE0GT035625; Tue, 1 Feb 2005 08:14:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11GE09A035624; Tue, 1 Feb 2005 08:14:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GE0cf035618 for ; Tue, 1 Feb 2005 08:14:00 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 39404 invoked by uid 17064); 1 Feb 2005 16:13:59 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2005 16:13:59 -0000 In-Reply-To: References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> <65500128-7468-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1b001abd85a5ea06012018902f1be25f@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "Roy T. Fielding" , Tim Bray From: Henry Story Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 17:13:53 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Duh. Sorry. It is a functional property. I explained why myself at length here: All the rest can arguably be thought to be overspecification. Henry Story On 1 Feb 2005, at 17:06, Henry Story wrote: > > Yes, the id is an inverse functional property relating an Entry to a > URI/IRI. > It is really just as simple as that. See the Ontology at: > > > > All the rest is over specification. > From owner-atom-syntax@mail.imc.org Tue Feb 1 11:41:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23109 for ; Tue, 1 Feb 2005 11:41:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GQYHM036593; Tue, 1 Feb 2005 08:26:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11GQYsY036592; Tue, 1 Feb 2005 08:26:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11GQXQD036585 for ; Tue, 1 Feb 2005 08:26:33 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j11FlZV2026698; Tue, 1 Feb 2005 15:47:41 GMT In-Reply-To: References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-116636584; protocol="application/pkcs7-signature" Message-Id: <5989b8f12e4bb0547d5060f06e2e9404@mac.com> Cc: Atom Syntax , Antone Roundy From: Graham Subject: Re: Comments on format-05 Date: Tue, 1 Feb 2005 15:47:34 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4-116636584 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 31 Jan 2005, at 7:02 pm, Mark Nottingham wrote: > If the concern about multiple content is solely that it will result in > more bandwidth use, I think it's misplaced; people who are concerned > about bandwidth won't publish multiple representations inline; forcing > them not to by legislation is misguided. It's the implementation costs at the client. If you allow multiple content of the same mime-type, even minimal software has to have a significantly more complicated interface to allow users to choose which one to show, and a significantly more complex database to make it happen. Big fat -1. Graham --Apple-Mail-4-116636584 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAxMTU0NzM1WjAjBgkqhkiG9w0BCQQxFgQUhKjsIS66sixwFCh5uLugTUzm jfYweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAEDhyPH00qsO07QJF9lpyx6ZJ HKtxy4kBPTxvDU5OIQhsORLDASeg6gmJpUR+sRZvjuqMnqkyu+D/2g2SkxB3stB21Pgt96qbGSch 4cJE43be7oGFqfWa9taihW2ltduVV22TO6NlzpDD6BSn67Y11YD7o6sNJq8J6PQx7UkeMUY+FPWR wax0pyIJw+DLLWumry1jPSLM+/K7v/RLvDSaZG4amilIbpazHP62Tzxo2TH3gdqBYp2wRJVLi+DH 0J8+y+IoEZ014Roi0mcXpuhcmnozdN3IY6o7Cs45c/vnVC90dSVT0Ntx1lQVa6GX1uRzmKfL97y2 QdZWdFDZEfhRpgAAAAAAAA== --Apple-Mail-4-116636584-- From owner-atom-syntax@mail.imc.org Tue Feb 1 12:20:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26206 for ; Tue, 1 Feb 2005 12:20:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11H03OX038870; Tue, 1 Feb 2005 09:00:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11H037m038869; Tue, 1 Feb 2005 09:00:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11H03Wl038863 for ; Tue, 1 Feb 2005 09:00:03 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 88090 invoked by uid 17064); 1 Feb 2005 17:00:00 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.140.72]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 1 Feb 2005 17:00:00 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1dfef65b7dc50ae487725fb36aa668b3@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: Dereferencing Identity Constructs Date: Tue, 1 Feb 2005 17:59:51 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ahhh! Here I make the mistake again. The id relation, relating an Entry and a Identity Construct is functional, not inverse functional. Hence an Entry can only have one id relation to a URI of type identity construct. But there is a way out of this: if an entry has a number of id relations, then one is forced to conclude that those identity constructs have the relation "same as". So if one had Atom Robots run Amok http://bblfish.net/blog/ tag://bblfish.net/eternalid/for/that/story ... Then one would be forced to conclude that rdf:sameAs (wink to advanced rdfers: is that ok?) for rdf newbies with primary mathematics background consider the function f(x) = x * 25 so f(0) = 0 f(1) = 25 f(2) = 50 etc. if we are told that f(a) = 100 and f(a) = 2*50 then we can conclude that 100 == 2*50 Henry Story On 31 Jan 2005, at 16:25, Henry Story wrote: > > One way to get people to have their cake and eat it too, may be to > allow multiple id tags. > Since an id is an inverse functional relationship between an Entry a > Resource this should > not cause any trouble. In any case there will never be any way you can > limit the number of > names a thing has. > > Henry Story > From owner-atom-syntax@mail.imc.org Tue Feb 1 13:08:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01839 for ; Tue, 1 Feb 2005 13:08:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11HpJbw042397; Tue, 1 Feb 2005 09:51:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11HpJ7Z042396; Tue, 1 Feb 2005 09:51:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11HpIIP042388 for ; Tue, 1 Feb 2005 09:51:18 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j11HnHxB010874; Tue, 1 Feb 2005 17:49:33 GMT In-Reply-To: <42205ff29bfeb8b51384a732a85d8870@bblfish.net> References: <13E35C6E-7408-11D9-8C3E-003065EA6144@geckotribe.com> <41FF0493.7000803@franklinmint.fm> <42205ff29bfeb8b51384a732a85d8870@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-5-123932851; protocol="application/pkcs7-signature" Message-Id: <31cfa90eb45b7b558506ac33a2dd191c@mac.com> Cc: Atom Syntax , Antone Roundy , Robert Sayre From: Graham Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted Date: Tue, 1 Feb 2005 17:49:11 +0000 To: Henry Story X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-5-123932851 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 1 Feb 2005, at 1:08 pm, Henry Story wrote: > > What is really needed here is some principled reasoning [1]. Otherwise > we will be left > clambering in the dark caverns of our individual prejudices. > > I suggest that when people make statements in favor or against > something, principled reasons > be given. It should be possible then to discuss the validity of the > claims (are things truly > the way stated), and the strength of the principles on which they rely. > > Perhaps it would also be useful to remember that the number of ways > things can be is > exceedingly large, and that often wars about what seem to be > incompatible perspectives > in the end turn out to be complimentary. +1 Graham --Apple-Mail-5-123932851 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAxMTc0OTEyWjAjBgkqhkiG9w0BCQQxFgQUaJd40XWr63BUIMAc4w/xUvYG qosweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAIAAH9d1CINchprRoB061hB8U 56YGWucT/8qODEvhwnRlKz+ySu838aLo69v4lcisWdiG4dW3EDGZoS1OHnljaPT7nEv4ThWN/fYH eoLp43C1YTxciUT1EFoqw5BFy+byWe07pcF20Cio2o/JxwtRHknjKsok9HeX8n5qkDLq4sbeXL6X +XSbXzoFazk+P8N+/GAcwshxjvVQ9OqWbGGYfLBLhb8lCxr9jwi+72fiYh/gu1pnFM8vjnL/ZxzE ARIgv2IOsPDLl3931WUF7PpZnopX9D71KvgALav7biWoDp5dbXGrT8mXU4s7H2YZgMgAdTLMZf7R 4XKoMnspAPyGTwAAAAAAAA== --Apple-Mail-5-123932851-- From owner-atom-syntax@mail.imc.org Tue Feb 1 13:24:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03157 for ; Tue, 1 Feb 2005 13:24:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11I2wlq043137; Tue, 1 Feb 2005 10:02:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11I2wno043136; Tue, 1 Feb 2005 10:02:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11I2vaR043130 for ; Tue, 1 Feb 2005 10:02:58 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D012F51A34; Tue, 1 Feb 2005 13:02:56 -0500 (EST) In-Reply-To: <5989b8f12e4bb0547d5060f06e2e9404@mac.com> References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> <5989b8f12e4bb0547d5060f06e2e9404@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <146833169bd1e57fe8690892bee5081e@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Antone Roundy X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Comments on format-05 Date: Tue, 1 Feb 2005 10:02:49 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Using XPath as a yardstick, what's so complex about this? /atom:feed/atom:entry[1]/atom:content[@type='HTML'|@type='TEXT'][0] I'm not even sure how I'd approach choosing between HTML and text in the current approach, where one is in atom:content and the other is referred to by atom:link; I'd need to use XSLT, I suspect. If your software only wants to live in a world where entries have only one type of content, it's maybe a few lines of extra code to choose one, and no change to the database. Atom doesn't require you to persist all of the entry. On Feb 1, 2005, at 7:47 AM, Graham wrote: > On 31 Jan 2005, at 7:02 pm, Mark Nottingham wrote: > >> If the concern about multiple content is solely that it will result >> in more bandwidth use, I think it's misplaced; people who are >> concerned about bandwidth won't publish multiple representations >> inline; forcing them not to by legislation is misguided. > > It's the implementation costs at the client. If you allow multiple > content of the same mime-type, even minimal software has to have a > significantly more complicated interface to allow users to choose > which one to show, and a significantly more complex database to make > it happen. > > Big fat -1. > > Graham -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Feb 1 13:34:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04210 for ; Tue, 1 Feb 2005 13:34:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11IHgDe044063; Tue, 1 Feb 2005 10:17:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11IHgE6044062; Tue, 1 Feb 2005 10:17:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11IHfC9044049 for ; Tue, 1 Feb 2005 10:17:42 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cw2aj-0000hH-KF; Tue, 01 Feb 2005 18:17:33 +0000 Message-ID: <41FFC7BD.7@franklinmint.fm> Date: Tue, 01 Feb 2005 13:17:33 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Graham , Atom Syntax , Antone Roundy Subject: Re: Comments on format-05 References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> <5989b8f12e4bb0547d5060f06e2e9404@mac.com> <146833169bd1e57fe8690892bee5081e@mnot.net> In-Reply-To: <146833169bd1e57fe8690892bee5081e@mnot.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > Using XPath as a yardstick, what's so complex about this? > > /atom:feed/atom:entry[1]/atom:content[@type='HTML'|@type='TEXT'][0] > > I'm not even sure how I'd approach choosing between HTML and text in > the current approach, where one is in atom:content and the other is > referred to by atom:link; I'd need to use XSLT, I suspect. > > If your software only wants to live in a world where entries have only > one type of content, it's maybe a few lines of extra code to choose > one, and no change to the database. Atom doesn't require you to > persist all of the entry. We dropped multiple content elements months ago, with good reason. Two of the more serious concerns were accessbility and the fact that nobody uses them in Atom 0.3. As I understand it, the only reason they were there originally was for uploading photos, an approach which is no longer necessary. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 1 13:35:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04516 for ; Tue, 1 Feb 2005 13:35:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11IIdYW044134; Tue, 1 Feb 2005 10:18:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11IIciV044133; Tue, 1 Feb 2005 10:18:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11IIcWE044125 for ; Tue, 1 Feb 2005 10:18:38 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j11IHaYp022862; Tue, 1 Feb 2005 18:17:41 GMT In-Reply-To: <146833169bd1e57fe8690892bee5081e@mnot.net> References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> <5989b8f12e4bb0547d5060f06e2e9404@mac.com> <146833169bd1e57fe8690892bee5081e@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-125638328; protocol="application/pkcs7-signature" Message-Id: <9f563b45c1305b38f11718635c7b2193@mac.com> Cc: Atom Syntax , Antone Roundy From: Graham Subject: Re: Comments on format-05 Date: Tue, 1 Feb 2005 18:17:36 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6-125638328 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit There's an awful lot more to an aggregator than the 3 lines that pull stuff out of XML. My problem is that users want to see the content in their preferred language, which means I have to provide some mechanism to choose, which may end up being the most complex part of a simple app. Additionally, think about search. Which content to do I look at? If I look at both or all languages, do I display the 2 or more versions of the same entry in the results? This is not easy to do with elegant GUI code and requires a much more complex object model. And as I said, no one is going to use the functionality anyway. Graham --Apple-Mail-6-125638328 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAxMTgxNzM3WjAjBgkqhkiG9w0BCQQxFgQUJfsRmiCmX87/HgPGdyYiT80C YccweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAZKxth65znVHYWdXsOlHlC07r 2hB03Zet27W0KjIBlCafK5Q0gQvWhn6K6pM/lf/qfG8ZDt4sVm8T6KkW1IYNRN0XWBS6ndgSq/sU uUIoSe+cVd+l8R8PtiCtpKwb6bQ0IMUsr0OJGZyT1bZRO9xmtIbpxx1VDqMmIlWBsnGO4lKa933o mMA+7EUufcV1iZdHIXZ5G7LQQcQQYWtUYZc5UxX4J+qAbZC2u+BIlIcgA6ihhD0ejvyXq4aml/m0 xGE+cJNqn5632HnsSniE7I8nbyBqaTJ3pqp3zGCFW2AZObdsY3TvpCA0C6ubdiOMTDNwFknEYwWS 788V/ThzUJ7PcQAAAAAAAA== --Apple-Mail-6-125638328-- From owner-atom-syntax@mail.imc.org Tue Feb 1 14:08:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07346 for ; Tue, 1 Feb 2005 14:08:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Io69S047435; Tue, 1 Feb 2005 10:50:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11Io6FP047434; Tue, 1 Feb 2005 10:50:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Io5tZ047428 for ; Tue, 1 Feb 2005 10:50:05 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j11Io1kc012046; Tue, 1 Feb 2005 13:50:01 -0500 (EST) Message-ID: <41FFCF58.2020800@intertwingly.net> Date: Tue, 01 Feb 2005 13:50:00 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: Atom Syntax Subject: Re: URI canonicalization References: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> <41FF7AB0.9060406@intertwingly.net> <3224313102ae27766d07e245e6042bfb@bblfish.net> In-Reply-To: <3224313102ae27766d07e245e6042bfb@bblfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > > On 1 Feb 2005, at 13:48, Sam Ruby wrote: > >> Roy T. Fielding wrote: >> >>> There is no reason to require any particular comparison algorithm. >>> One application is going to compare them the same way every time. >>> Two different applications may reach different conclusions about >>> two equivalent identifiers, but nobody cares because AT WORST the >>> result is a bit of inefficient use of storage. >> >> It is worse than that. To give a concrete example: Radio Userland's >> aggregator will not present to you an item that you have seen before, >> no matter how different the current content is. > > So? They will just go out of business, as people find better aggregators > or editors. > Leaves a bit of space for my Open Source, BSD licenced BlogEd to make > headway. That was just one example. NetNewsWire will correlate messages with equivalent ids and optionally present HTML diffs. Identifying which messages have been seen before and which ones have not is a significant area where the user experience with current aggregators has been suboptimal. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 1 14:16:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08501 for ; Tue, 1 Feb 2005 14:16:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Iu7Y7047822; Tue, 1 Feb 2005 10:56:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11Iu7Rg047821; Tue, 1 Feb 2005 10:56:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Iu2Le047813 for ; Tue, 1 Feb 2005 10:56:06 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9793D51ACF; Tue, 1 Feb 2005 13:56:01 -0500 (EST) In-Reply-To: <9f563b45c1305b38f11718635c7b2193@mac.com> References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> <5989b8f12e4bb0547d5060f06e2e9404@mac.com> <146833169bd1e57fe8690892bee5081e@mnot.net> <9f563b45c1305b38f11718635c7b2193@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48e05975d5da544f6fcd3f77523146ee@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Antone Roundy X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Comments on format-05 Date: Tue, 1 Feb 2005 10:56:00 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 10:17 AM, Graham wrote: > There's an awful lot more to an aggregator than the 3 lines that pull > stuff out of XML. My problem is that users want to see the content in > their preferred language, which means I have to provide some mechanism > to choose, which may end up being the most complex part of a simple > app. I agree that varying representations in the feed by language isn't productive, when you can vary the whole feed by language. I haven't been arguing that we should allow variance by language. To be clear, I'm less interested in allowing people to put multiple representations in the feed (although I think it should be possible; e.g., for archiving -- which we're chartered to enable) than I am in making sure people understand that it's possible to have more than one representation for a resource. So, I'm not going to lie in the road to defend multiple content, but would ask for an adjustment in the language to clarify things; From: [[[ 4.15 The "atom:content" Element The "atom:content" element either contains or links to the content of the entry. ]]] to: [[[ 4.15 The "atom:content" Element The "atom:content" element conveys a representation of the entry's content, either by containing it directly, or by linking to it. Other representations of the entry may exist; see the atom:link element. ]]] > And as I said, no one is going to use the functionality anyway. Wow, that's a nifty trick. If you can tell me the outcome of the Superbowl next week, I'll cut you into the proceeds. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Tue Feb 1 14:42:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11000 for ; Tue, 1 Feb 2005 14:42:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11JKlKu049239; Tue, 1 Feb 2005 11:20:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11JKl3F049238; Tue, 1 Feb 2005 11:20:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11JKguE049232 for ; Tue, 1 Feb 2005 11:20:46 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j11JKWkc007470; Tue, 1 Feb 2005 14:20:33 -0500 (EST) Message-ID: <41FFD681.3030000@intertwingly.net> Date: Tue, 01 Feb 2005 14:20:33 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: "Roy T. Fielding" , Atom Syntax Subject: Re: URI canonicalization References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> <65500128-7468-11D9-9797-000A95A51C9E@sun.com> In-Reply-To: <65500128-7468-11D9-9797-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: > >> Over-specification is just too fun. So that would mean I am >> required by Atom format to treat two different entries with the id >> "http://tbray.org/uid/1000" >> as the same entry, even when I received the first one >> from tbray.org and the second from mymonkeysbutt.net? >> >> Oh yeah, that'll be fun. ;-) > > Well, it would be much better than we have now. Anyone who subscribes > to aggregations (for example, I subscribe to the planetsun.org > aggregated feed), is used to seeing the same entry over and over and > over again. This problem is only going to get worse. With Atom's ID > semantics and compulsory timestamp, I would hope that my > aggregator would have a chance of not showing me the same entry unless > it's got a later timestamp than what I've seen. -Tim Also remember that subscriptions are "opt-in". I may chose to subscribe to PlanetApache.org (with whom I have a modicum of trust), but not to mymonkeysbutt.net (with which I presumably don't). - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 1 14:48:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11707 for ; Tue, 1 Feb 2005 14:48:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11JSkQm049690; Tue, 1 Feb 2005 11:28:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11JSkrO049689; Tue, 1 Feb 2005 11:28:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11JSkNJ049683 for ; Tue, 1 Feb 2005 11:28:46 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j11JSkdt006004 for ; Tue, 1 Feb 2005 12:28:46 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB800KOGZFR7U@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 12:28:40 -0700 (MST) Received: from [66.103.196.117] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB800573ZFPUN@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 12:28:39 -0700 (MST) Date: Tue, 01 Feb 2005 11:28:44 -0800 From: Tim Bray Subject: Re: Comments on format-05 In-reply-to: <41FFC7BD.7@franklinmint.fm> To: Robert Sayre Cc: Graham , Atom Syntax , Mark Nottingham , Antone Roundy Message-id: <7C6CBB37-7487-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <4FA8C461-73B6-11D9-8C3E-003065EA6144@geckotribe.com> <5989b8f12e4bb0547d5060f06e2e9404@mac.com> <146833169bd1e57fe8690892bee5081e@mnot.net> <41FFC7BD.7@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 1, 2005, at 10:17 AM, Robert Sayre wrote: > We dropped multiple content elements months ago, with good reason. Two > of the more serious concerns were accessbility and the fact that > nobody uses them in Atom 0.3. As I understand it, the only reason they > were there originally was for uploading photos, an approach which is > no longer necessary. No, it was there also as an accessibility measure, but the constraints on src= and the requirement for a summary in some cases do a better job. -Tim From owner-atom-syntax@mail.imc.org Tue Feb 1 15:24:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15778 for ; Tue, 1 Feb 2005 15:24:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11K5P7L052007; Tue, 1 Feb 2005 12:05:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11K5PI9052006; Tue, 1 Feb 2005 12:05:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11K5PXs051994 for ; Tue, 1 Feb 2005 12:05:25 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050201200519014003icnie>; Tue, 1 Feb 2005 20:05:20 +0000 Date: Tue, 1 Feb 2005 13:05:18 -0700 Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42205ff29bfeb8b51384a732a85d8870@bblfish.net> Message-Id: <9831AF60-748C-11D9-9FA4-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, February 1, 2005, at 06:08 AM, Henry Story wrote: ... Without taking the trouble to purchase and read the book you pointed to, here is my reasoning: >> Antone Roundy wrote: >> >>> My preferences: >>> >>> +1: Current draft or PaceAggregationDocument (with or without >>> atom:feed/atom:head and with or without metadata for >>> atom:aggregation (atom:aggregation/atom:head?)) Stable paths to the elements of a feed. Greatest simplicity--certainly the way that I implement my code, these are the simplest. >>> +0.5: PaceFeedRecursive without any more indirection than we already >>> have, and only one level of recursion Less stable paths to elements since you don't know in advance whether the entries will be in the outermost feed, or whether some or all of them will be inside another feed layer. >>> -0.8: Real RDF I think we've discussed this one enough--RDF adds overhead that I don't value. Others do. I don't. >>> -1: PaceFeedRecursive as it stands (no extra indirection, but >>> unlimited levels of recursion) I don't want to have to deal with the added complexity of potentially unlimited recursion, nor do I see value in allowing it. Sure, it can show you the long list of feeds that an entry traversed to get from its original feed to the current feed, but for those who value that more than I do, there MUST be a better way to do it. >>> -1.5: "add an attribute to atom:entry that indicates whether it >>> refers to an instance of entry or another feed" I'm not entirely sure what is intended by this, but it sounds like a combination of unlimited recursion and not even knowing whether and entry is an entry or a feed without examining it's attributes. I assume this is basically "a feed is an entry, so let's use the same element for both"? >>> -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 that don't hand of HTML content to some widget for handling, and thus have to handle the details of loading images and such themselves, but for applications that do, it's much simpler to be able to get everything that they need to manipulate with one request and be done with it. We already have indirection for , which I personally would be happier without. I'd like to avoid adding more. From owner-atom-syntax@mail.imc.org Tue Feb 1 15:49:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18243 for ; Tue, 1 Feb 2005 15:49:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11KSlvK053446; Tue, 1 Feb 2005 12:28:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11KSlR6053445; Tue, 1 Feb 2005 12:28:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11KSkqF053427 for ; Tue, 1 Feb 2005 12:28:46 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so77550rnz for ; Tue, 01 Feb 2005 12:28:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=anQcEyWSyXULQ2Q60PAgFGow6VW3LfS/IeZR8cdWQFClNsxEfUquOR6FPd675Mwni7WnfrtzNil9pVWy5tIKX7J0OoTxNTf6ZLSC3Dxi+ra2WKCUZ7f8niKl3K7HsI+Ku+4Ed+oK2isCpwm1Xez3qqb3Y5rLMyGNmtsWAbLwOGs= Received: by 10.38.179.56 with SMTP id b56mr264044rnf; Tue, 01 Feb 2005 12:28:40 -0800 (PST) Received: by 10.38.179.71 with HTTP; Tue, 1 Feb 2005 12:28:40 -0800 (PST) Message-ID: <1f2ed5cd05020112287b37c5ad@mail.gmail.com> Date: Tue, 1 Feb 2005 21:28:40 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Henry Story Subject: Re: Dereferencing Identity Constructs Cc: Atom Syntax In-Reply-To: <1dfef65b7dc50ae487725fb36aa668b3@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1dfef65b7dc50ae487725fb36aa668b3@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm a little confused over what's being proposed or counterproposed here - I thought consensus last year was to break the Web.... Whatever, I do think URIs should be treated as URIs according to webarch etc - it should be possible to dereference them, assuming that's supported by the scheme. The easiest implementation of a blog feed would be to have the referring to the resource entry that has a HTML representation in the blog. It seems perverse to build a whole new system of Web data reference around permalinks and assuming unCool URIs. Cheers, Danny. On Tue, 1 Feb 2005 17:59:51 +0100, Henry Story wrote: > > Ahhh! Here I make the mistake again. > > The id relation, relating an Entry and a Identity Construct is > functional, not inverse > functional. Hence an Entry can only have one id relation to a URI of > type identity construct. > > But there is a way out of this: if an entry has a number of id > relations, then one is forced > to conclude that those identity constructs have the relation "same as". > > So if one had > > > Atom Robots run Amok > http://bblfish.net/blog/ > tag://bblfish.net/eternalid/for/that/story > ... > > > Then one would be forced to conclude that > > rdf:sameAs > > > (wink to advanced rdfers: is that ok?) > > for rdf newbies with primary mathematics background consider the > function > > f(x) = x * 25 > > so f(0) = 0 > f(1) = 25 > f(2) = 50 > etc. > > if we are told that > > f(a) = 100 and f(a) = 2*50 > then we can conclude that 100 == 2*50 > > Henry Story > > On 31 Jan 2005, at 16:25, Henry Story wrote: > > > > One way to get people to have their cake and eat it too, may be to > > allow multiple id tags. > > Since an id is an inverse functional relationship between an Entry a > > Resource this should > > not cause any trouble. In any case there will never be any way you can > > limit the number of > > names a thing has. > > > > Henry Story > > > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 1 16:14:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21272 for ; Tue, 1 Feb 2005 16:14:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11L5Y2d056279; Tue, 1 Feb 2005 13:05:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11L5Y03056278; Tue, 1 Feb 2005 13:05:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j11L5WSh056265 for ; Tue, 1 Feb 2005 13:05:33 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 01 Feb 2005 21:05:26 -0000 Received: from pD953514A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.74) by mail.gmx.net (mp009) with SMTP; 01 Feb 2005 22:05:26 +0100 X-Authenticated: #1915285 Message-ID: <41FFEF0D.1090200@gmx.de> Date: Tue, 01 Feb 2005 22:05:17 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Format spec vs Protocol spec Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, (I raised this when reviewing draft 05 already, but I think this topic deserves it's own thread) Currently, the format spec has a normative reference to the protocol spec (and also defines elements for the service URIs, for instance, atom:introspection). As far as I understand the IETF publication process, this means that draft-ietf-atompub-format can't be published until the protocol spec is ready as well. 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. This would essentially de-couple the publication process. Thoughts? Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 1 17:23:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08664 for ; Tue, 1 Feb 2005 17:23:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M6whC060773; Tue, 1 Feb 2005 14:06:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11M6wLu060772; Tue, 1 Feb 2005 14:06:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11M6vOO060765 for ; Tue, 1 Feb 2005 14:06:57 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 8D6C14F4D0; Tue, 1 Feb 2005 17:06:54 -0500 (EST) Message-Id: <6.0.0.20.2.20050201222841.06c81a10@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 01 Feb 2005 23:28:41 +0900 To: Sam Ruby From: Martin Duerst Subject: Re: Questions about -04 Cc: Asbj , Atom Syntax In-Reply-To: <41F85466.7070005@intertwingly.net> References: <873bx6x1z1.fsf@nwalsh.com> <41E59C93.4050001@intertwingly.net> <6.0.0.20.2.20050126100322.07746e30@localhost> <41F85466.7070005@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sorry, this was way back, but caught my eye again. At 11:39 05/01/27, Sam Ruby wrote: > >Martin Duerst wrote: >> At 01:51 05/01/26, Asbj n Ulsberg wrote: >> > >> >On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby >> >wrote: >> > >> >>> 2. Why MUST a feed point to an alternate version. [...] >> >> >> >> I'm -1 on removing this restriction. >> > >> >I thought we came to a sort of consensus that the link should be optional. >> >Or was that only for atom:entry? Anyway, I think both of them should be >> >optional. That is, I disagree with you, Sam. >> I agree with Asbjoern. Regards, Martin. > >There is consensus that atom:link is not required for atom:entries which >contain content. That consensus has been reflected in the most recent >drafts. That is not the question referred to above. Understood. >There are now, by some counts, ten versions of formats that call >themselves RSS. Every last one of then has a required channel/link. >Every last one of them. > >Relaxing a restriction requires consumers to handle more cases. How difficult can it possibly be, in this specific case? >My >expectation is that given limited demand for this feature, the more >likely scenario is that consumers will either produce unexpected results >or outright fail for feeds without this data. What do they need it for in the first place? >Because of this, I would like to request that there be a compelling use >case be found which for feeds for which there can not be a atom:link >defined. Is there a compelling use case (not "it has always been that way", which doesn't count as an use case) for requiring it? The use case for not having it is pretty straightforward: Just a feed. It's that simple. Feeds can live on their own. They don't need alternate Web pages, and if they don't have have them, it's just straightforward design to not require such an element. Everything else is just cheating ourselves. >Note atom:link is defined as a URI. While most examples that >we have seen use the HTTP scheme, this is not a requirement. Given that >this is not a requirement, and given that existing RSS producers have >come out in mass demanding that this restriction be lifted from RSS, I >can only conclude that the burden seems rather low. So you are saying that ... is better than just leaving that out? Do we want the above nonsense to go into the RDF model, and so on? Isn't it much more straightforward to model the format after actual and potential realities, rather than to have to cheat? Regards, Martin. From owner-atom-syntax@mail.imc.org Tue Feb 1 17:49:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11322 for ; Tue, 1 Feb 2005 17:49:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11MXBml062731; Tue, 1 Feb 2005 14:33:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11MXB6t062730; Tue, 1 Feb 2005 14:33:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11MXB9m062721 for ; Tue, 1 Feb 2005 14:33:11 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050201223305014003da2he>; Tue, 1 Feb 2005 22:33:05 +0000 Date: Tue, 1 Feb 2005 15:33:04 -0700 Subject: Re: URI canonicalization Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> Message-Id: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, January 31, 2005, at 10:57 PM, Roy T. Fielding wrote: > There is no reason to require any particular comparison algorithm. > One application is going to compare them the same way every time. > Two different applications may reach different conclusions about > two equivalent identifiers, but nobody cares because AT WORST the > result is a bit of inefficient use of storage. > > The guidance, if any, should simply state that identifier > constructs must be unique. It is not our responsibility to > prevent people from assigning the same (equivalent) identifiers > to two different resources, nor do I care how many errors > occur when they violate such a basic requirement. > While we certainly shouldn't be in the business of saying "IDs MUST be compared using the C function 'strcmp'", I think we need to be specific about what it means for an IDs to be unique. Given that we're using URIs as IDs, and two URIs can be functionally identical without being characterwise identical, we need to explain that we mean by "unique". If we don't want to mandate a particular algorithm, then we need to find a way to get the point across some other way. Perhaps (the first sentence is the existing first sentence): Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. The values of two Identity constructs are considered to be the same if a case-sensitive character-by-character comparison would recognize them as identical. This language doesn't mandate actually performing a "case-sensitive character-by-character comparison", but it should be clear from the this language what it means to be the same. If we want to get even further from talking about algorithms, we could go with something like this, but it begins to sound a little strained: Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. The values of two Identity constructs are considered to be the same if they contain exactly the same code points in exactly the same order. If we want to get even more precise, and don't mind getting more wordy: Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. The values of two Identity constructs are considered to be the same if, after XML deserialization, but before any other processing such as decoding of percent-encoded characters, they contain exactly the same code points in exactly the same order. From owner-atom-syntax@mail.imc.org Tue Feb 1 18:16:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13846 for ; Tue, 1 Feb 2005 18:16:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11N6nqv064872; Tue, 1 Feb 2005 15:06:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11N6nQA064871; Tue, 1 Feb 2005 15:06:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11N6mnM064858 for ; Tue, 1 Feb 2005 15:06:48 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050201230636.EPOO1139.mta05-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com> for ; Tue, 1 Feb 2005 23:06:36 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050201230636.GVEC3971.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for ; Tue, 1 Feb 2005 23:06:36 +0000 Date: Tue, 1 Feb 2005 23:06:34 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <158887418.20050201230634@djpowell.net> To: Atom Syntax Subject: Entry order MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Is the order of entries within a feed supposed to be significant? I can't see anything in the spec. I think we should say something - I'm guessing that it is not significant, and any ordering should be done using atom:updated or atom:published. It looks like this might have got lost accidently when the atom:head element was introduced. Previously Atom 0.3 said [1]: > Ordering of the element children of atom:feed element MUST NOT be > considered significant. [1] http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html#rfc.section.4 -- Dave From owner-atom-syntax@mail.imc.org Tue Feb 1 18:17:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14000 for ; Tue, 1 Feb 2005 18:17:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11N6un3064893; Tue, 1 Feb 2005 15:06:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11N6ube064888; Tue, 1 Feb 2005 15:06:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta13-winn.mailhost.ntl.com (smtpout19.mailhost.ntl.com [212.250.162.19]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11N6rdm064865; Tue, 1 Feb 2005 15:06:54 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta07-winn.mailhost.ntl.com ([212.250.162.8]) by mta13-winn.mailhost.ntl.com with ESMTP id <20050201230647.UHCI11211.mta13-winn.mailhost.ntl.com@aamta07-winn.mailhost.ntl.com>; Tue, 1 Feb 2005 23:06:47 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta07-winn.mailhost.ntl.com with ESMTP id <20050201230647.GVPB3971.aamta07-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com>; Tue, 1 Feb 2005 23:06:47 +0000 Date: Tue, 1 Feb 2005 22:58:30 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1356745329.20050201225830@djpowell.net> To: Mark Nottingham CC: Robert Sayre , Paul Hoffman , Atom WG , Tim Bray Subject: Re: Feed State [was: Work Queue Rotation #16] In-Reply-To: References: <9d93e3488ff803c3dfd4ea9223f06352@bea.com> <41FEEC9D.8020006@franklinmint.fm> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tuesday, February 1, 2005, 5:18:44 AM, you wrote: > P.S. Feed Document may be somewhat misleading, because it's easy to > confuse it with Feed (which has connotations of the information > channel). I think "Feed Snapshot Document" or the like was once > proposed, but it was shot down. *shrug* In my RDF mapping I modelled the thing with the id as a "Feed", and used "FeedInstance" as a term for the version of feed properties that is delivered in the document. Same for "Entry" and "EntryInstance". It is clear that feeds and entries are expected to change so I modelled the different instances as separate entities. This way you can use the same model whether you only care about the latest instance, or if you want to keep historic instances. [*] Anyway - would it be worth using the term "Entry Instance" in the spec? Would it make ids easier to explain? * You'd annotate each instance with something like atomrdf:receivedDate so that you can select the latest version. It works well from RDF - because you are no longer negating information every time something changes, instead you are just taking a selective view on the most recent version of what is available. -- Dave From owner-atom-syntax@mail.imc.org Tue Feb 1 18:21:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14485 for ; Tue, 1 Feb 2005 18:21:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11NBB7O065167; Tue, 1 Feb 2005 15:11:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11NBBk5065166; Tue, 1 Feb 2005 15:11:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11NBAw2065159 for ; Tue, 1 Feb 2005 15:11:10 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j11N3X2R020943; Tue, 1 Feb 2005 23:03:39 GMT In-Reply-To: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> References: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-142793871; protocol="application/pkcs7-signature" Message-Id: <0b5370fb888a1d601c43673f18b17d6d@mac.com> Cc: atom-syntax@imc.org From: Graham Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 23:03:32 +0000 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-7-142793871 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 1 Feb 2005, at 10:33 pm, Antone Roundy wrote: > Instances of Identity constructs can be compared to determine > whether > an entry or feed is the same as one seen before. The values of two > Identity constructs are considered to be the same if a > case-sensitive > character-by-character comparison would recognize them as identical. Aren't we approaching this problem from the wrong end? The id spec should be instructions for publishers saying "Any two versions of the same entry must use the same id, which requires that all characters are the same. Any two different entries must have different ids, which requires that at least one character is different [we could also go further and say they should canonicalize to different things or some such]." That way publishers know what to do, consumers know what the publishers are trying to express, but aren't constrained in their implementations, and we also define "permanent" and "universally unique", which the current spec fails to. Graham --Apple-Mail-7-142793871 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAxMjMwMzMyWjAjBgkqhkiG9w0BCQQxFgQUfpMqxSZPWeP0JQtsT1rScPbe 8IoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAjq2UyCGI3bbrU/QY2YEcCjhc zde9z+v1nal2ImEagp9IwgggvTD4LGUe0KWlUc9xvjBxV0nysFgJ56i2bs0T9EEwF1jPeg6jEhfC lcinYGP46kRdU3OA8D9utW53O02JxSgM+bQPgebvK1LJJyujeKZcpgsHVsYx2b3slL7dKIcDvnV9 sJPwX5OebdV9BE+9OmQ2KdNQS55p8IibgpsId53WNqFcWD/sPoOlJG9No3R+2brLx6oGxmB+DxUS V32TogtB4h+J2g2gQr9whoATHF4TbCx5mvgDGDLIetyk5N1wZRMnyCKkNt4Qbpvuy+qSL93hMkmr WR8WO+yWszbE8gAAAAAAAA== --Apple-Mail-7-142793871-- From owner-atom-syntax@mail.imc.org Tue Feb 1 18:44:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16599 for ; Tue, 1 Feb 2005 18:44:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11NZCcM066720; Tue, 1 Feb 2005 15:35:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11NZCbX066719; Tue, 1 Feb 2005 15:35:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11NZBVg066637 for ; Tue, 1 Feb 2005 15:35:11 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 2 Feb 2005 12:34:13 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 02 Feb 2005 10:33:24 +1100 Subject: Re: URI canonicalization From: Eric Scheid To: Graham , Antone Roundy CC: Atom Syntax Message-ID: In-Reply-To: <0b5370fb888a1d601c43673f18b17d6d@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2/2/05 10:03 AM, "Graham" wrote: > Aren't we approaching this problem from the wrong end? The id spec > should be instructions for publishers saying "Any two versions of the > same entry must use the same id, which requires that all characters are > the same. Any two different entries must have different ids, which > requires that at least one character is different [we could also go > further and say they should canonicalize to different things or some > such]." That way publishers know what to do, consumers know what the > publishers are trying to express, but aren't constrained in their > implementations, and we also define "permanent" and "universally > unique", which the current spec fails to. +1 From owner-atom-syntax@mail.imc.org Tue Feb 1 19:24:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20978 for ; Tue, 1 Feb 2005 19:24:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120Bf4N068796; Tue, 1 Feb 2005 16:11:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120Bere068795; Tue, 1 Feb 2005 16:11:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120BeiJ068788 for ; Tue, 1 Feb 2005 16:11:40 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j120BdVu026816 for ; Tue, 1 Feb 2005 17:11:39 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9009NPCJF88@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 17:11:39 -0700 (MST) Received: from [10.192.52.83] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB90007OCJE8A@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 17:11:39 -0700 (MST) Date: Tue, 01 Feb 2005 16:11:47 -0800 From: Tim Bray Subject: Re: Format spec vs Protocol spec In-reply-to: <41FFEF0D.1090200@gmx.de> To: Julian Reschke Cc: Atom Syntax Message-id: <071DC87E-74AF-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <41FFEF0D.1090200@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: > Currently, the format spec has a normative reference to the protocol > spec (and also defines elements for the service URIs, for instance, > atom:introspection). I suggest this can and should be removed. --Tim From owner-atom-syntax@mail.imc.org Tue Feb 1 19:27:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21229 for ; Tue, 1 Feb 2005 19:27:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120KAHB069421; Tue, 1 Feb 2005 16:20:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120KAeR069420; Tue, 1 Feb 2005 16:20:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120K9L4069414 for ; Tue, 1 Feb 2005 16:20:10 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cw8FN-0004fK-VQ; Wed, 02 Feb 2005 00:19:54 +0000 Message-ID: <42001CAB.205@franklinmint.fm> Date: Tue, 01 Feb 2005 19:19:55 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Julian Reschke , Atom Syntax Subject: Re: Format spec vs Protocol spec References: <41FFEF0D.1090200@gmx.de> <071DC87E-74AF-11D9-968C-000A95A51C9E@sun.com> In-Reply-To: <071DC87E-74AF-11D9-968C-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: > >> Currently, the format spec has a normative reference to the protocol >> spec (and also defines elements for the service URIs, for instance, >> atom:introspection). > > > I suggest this can and should be removed. Agree. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 1 19:28:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21356 for ; Tue, 1 Feb 2005 19:28:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120INej069325; Tue, 1 Feb 2005 16:18:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120INwp069324; Tue, 1 Feb 2005 16:18:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120INaD069314 for ; Tue, 1 Feb 2005 16:18:23 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050202001813.SHRJ8882.fed1rmmtao06.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 19:18:13 -0500 In-Reply-To: <41FF7AB0.9060406@intertwingly.net> References: <889A0040-73AF-11D9-8C3E-003065EA6144@geckotribe.com> <7869b6ef042128a30be69f73edbe5ca6@gbiv.com> <41FF7AB0.9060406@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 16:18:12 -0800 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 4:48 AM, Sam Ruby wrote: > Roy T. Fielding wrote: >> There is no reason to require any particular comparison algorithm. >> One application is going to compare them the same way every time. >> Two different applications may reach different conclusions about >> two equivalent identifiers, but nobody cares because AT WORST the >> result is a bit of inefficient use of storage. > > It is worse than that. To give a concrete example: Radio Userland's > aggregator will not present to you an item that you have seen before, > no matter how different the current content is. So, at worst, if two different feeds use the same id, then the first one received will eclipse all later ones. How does requiring a specific comparison algorithm change that? The goal should be different ids, not jumping through hoops to artificially differentiate between equivalent URIs. Besides, I don't think that existing sites with obvious security holes should be used as an example for format requirements, unless said requirements are going to close those holes. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 19:39:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22957 for ; Tue, 1 Feb 2005 19:39:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120SOuO069827; Tue, 1 Feb 2005 16:28:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120SOYW069826; Tue, 1 Feb 2005 16:28:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao12.cox.net (fed1rmmtao12.cox.net [68.230.241.27]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120SOwj069820 for ; Tue, 1 Feb 2005 16:28:24 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao12.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050202002819.XGQA10388.fed1rmmtao12.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 19:28:19 -0500 In-Reply-To: <65500128-7468-11D9-9797-000A95A51C9E@sun.com> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> <65500128-7468-11D9-9797-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9b6db43366ad90efe3183b40e39cd1f8@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 16:28:18 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 7:46 AM, Tim Bray wrote: > On Jan 31, 2005, at 10:16 PM, Roy T. Fielding wrote: > >> Over-specification is just too fun. So that would mean I am >> required by Atom format to treat two different entries with the id >> "http://tbray.org/uid/1000" >> as the same entry, even when I received the first one >> from tbray.org and the second from mymonkeysbutt.net? >> >> Oh yeah, that'll be fun. ;-) > > Well, it would be much better than we have now. Anyone who subscribes > to aggregations (for example, I subscribe to the planetsun.org > aggregated feed), is used to seeing the same entry over and over and > over again. This problem is only going to get worse. With Atom's ID > semantics and compulsory timestamp, I would hope that my > aggregator would have a chance of not showing me the same entry unless > it's got a later timestamp than what I've seen. -Tim The problem is that the requirement you suggested removes their ability to use common sense in dealing with same-ID entries and remain compliant with the format. You don't need to tell aggregators how to implement their trust mechanism. Just tell them what the format means and they will either improve their presentation or lose to some other aggregator who does it right. If you do want to place requirements on aggregators, then please do so in a separate spec or in an appendix. That way, us folks who don't implement aggregators don't need to obey requirements that conflict with basic content management and security principles. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 19:39:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23029 for ; Tue, 1 Feb 2005 19:39:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120Undk069953; Tue, 1 Feb 2005 16:30:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120UnlT069952; Tue, 1 Feb 2005 16:30:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j120UlbB069943 for ; Tue, 1 Feb 2005 16:30:48 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Feb 2005 00:30:41 -0000 Received: from pD953514A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.83.81.74) by mail.gmx.net (mp027) with SMTP; 02 Feb 2005 01:30:41 +0100 X-Authenticated: #1915285 Message-ID: <42001F28.9070505@gmx.de> Date: Wed, 02 Feb 2005 01:30:32 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Tim Bray , Atom Syntax Subject: Re: Format spec vs Protocol spec References: <41FFEF0D.1090200@gmx.de> <071DC87E-74AF-11D9-968C-000A95A51C9E@sun.com> <42001CAB.205@franklinmint.fm> In-Reply-To: <42001CAB.205@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Tim Bray wrote: > >> >> On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote: >> >>> Currently, the format spec has a normative reference to the protocol >>> spec (and also defines elements for the service URIs, for instance, >>> atom:introspection). >> >> >> >> I suggest this can and should be removed. > > > > Agree. For the record: I made that proposal *although* I like the protocol bit a lot. I just want us to be able to progress both specs independently of each other. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 1 20:00:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24931 for ; Tue, 1 Feb 2005 20:00:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120qkoC071701; Tue, 1 Feb 2005 16:52:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j120qkd1071700; Tue, 1 Feb 2005 16:52:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao06.cox.net (fed1rmmtao06.cox.net [68.230.241.33]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j120qkWE071691 for ; Tue, 1 Feb 2005 16:52:46 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao06.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050202005241.SYJG8882.fed1rmmtao06.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 19:52:41 -0500 In-Reply-To: <0b5370fb888a1d601c43673f18b17d6d@mac.com> References: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> <0b5370fb888a1d601c43673f18b17d6d@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 16:52:40 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 3:03 PM, Graham wrote: > Aren't we approaching this problem from the wrong end? The id spec > should be instructions for publishers saying "Any two versions of the > same entry must use the same id, which requires that all characters > are the same. Any two different entries must have different ids, ... Yes, place the requirement where it will do some good. It is okay to require publishers to spell their URIs consistently. There is no need to explain what "different ids" means -- any two URIs that are different identifiers will never compare as "equivalent", regardless of the comparison algorithm used. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 20:24:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27277 for ; Tue, 1 Feb 2005 20:24:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121FOV0073435; Tue, 1 Feb 2005 17:15:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j121FOqD073434; Tue, 1 Feb 2005 17:15:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121FNYC073428 for ; Tue, 1 Feb 2005 17:15:23 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j121FNdt012405 for ; Tue, 1 Feb 2005 18:15:23 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB90093UFH788@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 18:15:08 -0700 (MST) Received: from [10.192.52.83] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB90000YFH48A@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 18:15:05 -0700 (MST) Date: Tue, 01 Feb 2005 17:15:12 -0800 From: Tim Bray Subject: Re: URI canonicalization In-reply-to: <9b6db43366ad90efe3183b40e39cd1f8@gbiv.com> To: "Roy T. Fielding" Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <6870BCEC-740B-11D9-9797-000A95A51C9E@sun.com> <65500128-7468-11D9-9797-000A95A51C9E@sun.com> <9b6db43366ad90efe3183b40e39cd1f8@gbiv.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 1, 2005, at 4:28 PM, Roy T. Fielding wrote: >> Anyone who subscribes to aggregations (for example, I subscribe to >> the planetsun.org aggregated feed), is used to seeing the same entry >> over and over and over again. This problem is only going to get >> worse. With Atom's ID semantics and compulsory timestamp, >> I would hope that my aggregator would have a chance of not showing me >> the same entry unless it's got a later timestamp than what I've seen. >> -Tim > > The problem is that the requirement you suggested removes their > ability to use common sense in dealing with same-ID entries and > remain compliant with the format. You don't need to tell aggregators > how to implement their trust mechanism. Just tell them what the > format means Uh... right. What are we supposed to be disagreeing about? I would think that a hint in the spec pointing out how you can use atom:id/atom:updated to improve handling of dupes in aggregated feeds couldn't hurt, I'm convinced that saying anything normative about what they should do won't help. -Tim From owner-atom-syntax@mail.imc.org Tue Feb 1 20:24:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27298 for ; Tue, 1 Feb 2005 20:24:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121D0dG073341; Tue, 1 Feb 2005 17:13:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j121D0lS073340; Tue, 1 Feb 2005 17:13:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j121Cx0P073319 for ; Tue, 1 Feb 2005 17:12:59 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j121CA1Z017689; Wed, 2 Feb 2005 01:12:16 GMT In-Reply-To: <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> References: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> <0b5370fb888a1d601c43673f18b17d6d@mac.com> <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-150511897; protocol="application/pkcs7-signature" Message-Id: <55a1072e9398a9140f5c508b6ca0c78d@mac.com> Cc: Atom Syntax From: Graham Subject: Re: URI canonicalization Date: Wed, 2 Feb 2005 01:12:10 +0000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-8-150511897 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: > There is no need to explain what "different ids" means -- any two > URIs that are different identifiers will never compare as > "equivalent", regardless of the comparison algorithm used. Pardon? If I use case sensitive ids (eg base64 style "http://www.example.com/aBCde" and "http://www.example.com/aBCdE" are different), and the client is case-insensitive, that's not going to work. Graham --Apple-Mail-8-150511897 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAyMDExMjEwWjAjBgkqhkiG9w0BCQQxFgQU0zuoUZSzCFClZCOM95SaJJPB lz8weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAHInMW9/rWqT66U6UTgdYkazu Alhe1D+f7PhIyi0RAv6SKQfMJirpdzXwXrYhk3qYVp2y6tUfj1pUSnWqFl/ePK8VWkhnstX33O+j ucEampZ7FnK0WbIVFBl1pRW6s6nABvYleKqVYwS/7hpDSrkqvTNIN0LR38SV0uQJrFSrE8NT4T7q +5Qk7ISXIYhJqkAGROnRxEZnpqUiQg9VU6CkhhQuK6V+HnMQ9k4ZKU/aoU47o+H6nKX8p/qokVUc 1ucNHNNGv5KRvegcVgz/NaNuqDBZ7ZCuF94G9XwV6EboqfwQSehXLquFHMvfAGF/LN0bizr5sSCo vVpRg1NNLsv2ZAAAAAAAAA== --Apple-Mail-8-150511897-- From owner-atom-syntax@mail.imc.org Tue Feb 1 21:23:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02621 for ; Tue, 1 Feb 2005 21:23:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122B9L5076756; Tue, 1 Feb 2005 18:11:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122B9IX076755; Tue, 1 Feb 2005 18:11:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122B8qT076749 for ; Tue, 1 Feb 2005 18:11:08 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j122B8dt013654 for ; Tue, 1 Feb 2005 19:11:08 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9009MBI2HSI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 19:11:08 -0700 (MST) Received: from [10.192.52.83] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB90000MI2H7R@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 19:11:05 -0700 (MST) Date: Tue, 01 Feb 2005 18:11:13 -0800 From: Tim Bray Subject: Trial format-05 atom feed To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT 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 http://www.tbray.org/ongoing/ongoing.atom I guess the only thing that's mildly interesting is that some entries have and others have depending on whether the whole thing's there. -Tim PS: if you open that URL in FireFox (on OS X anyhow), and FireFox asks you what program you'd like to open it in, do not (repeat NOT) tell FireFox to open it in FireFox. Trust me on this. From owner-atom-syntax@mail.imc.org Tue Feb 1 21:36:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03641 for ; Tue, 1 Feb 2005 21:36:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122PmYZ078416; Tue, 1 Feb 2005 18:25:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122PmEX078415; Tue, 1 Feb 2005 18:25:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao08.cox.net (fed1rmmtao08.cox.net [68.230.241.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122PmLo078403 for ; Tue, 1 Feb 2005 18:25:48 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050202022537.TSBF10309.fed1rmmtao08.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 21:25:37 -0500 In-Reply-To: <6.0.0.20.2.20050201163925.06e0acc0@localhost> References: <3d85f2510dfd35dea02f0f5746ea295b@mac.com> <6.0.0.20.2.20050201115102.06e44078@localhost> <42a367c55781a6c0012c222d5e4e8df9@gbiv.com> <6.0.0.20.2.20050201163925.06e0acc0@localhost> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 18:25:35 -0800 To: Martin Duerst X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Jan 31, 2005, at 11:56 PM, Martin Duerst wrote: > At 14:27 05/02/01, Roy T. Fielding wrote: > >That would be a falsehood. Identifiers are not subject to > >"simplification" -- they are either equivalent or not. We can > >add all of the implementation requirements we like to prevent > >software from detecting false negatives, but that doesn't change > >the fact that equivalent identifiers always identify the same > >resource. It is the author's responsibility to use URIs > >(or IRIs) that are actually different, not the responsibility > >of the protocol or implementation. > > It's okay for some network-oriented usage to work that way. > The network can fail any moment, anyway. But it's not helpful > at all in some contexts that are not network-oriented. A very > good case in point would be XML Namespaces. In that case, > unless there is a single rule for comparison that can be used > by all implementations, it would lead to some XML being > declared namespace valid by one XML processor, and not > namespace valid by some other XML processor. Where is this myth coming from? If a single document uses two different URIs to name the same namespace (or multiple documents using different URIs are merged) then an XML processor will consider those qualified names as different names. That does not change their validity whatsoever. It doesn't even change their data model, since to be equivalent the two URIs must refer to the same namespace and therefore the same data model. Validity is a property of DTDs and Schema, not XML namespace processing, and neither DTDs nor Schema are able to redefine the meaning of URIs. The only purpose of the comparison algorithm is to allow those technologies to take the shortcut of evaluating structures based solely on the strcmp URI comparison, leaving false-negatives to be resolved by the author. > >I am disappointed that a MUST requirement was added to IRI in the > >last draft without working group review. This part > > > > Applications using IRIs as identity tokens with no relationship to > a > > protocol MUST use the Simple String Comparison (see section 5.3.1). > > All other applications MUST select one of the comparison practices > > from the Comparison Ladder (see section 5.3 or, after IRI-to-URI > > conversion, select one of the comparison practices from the URI > > comparison ladder in [RFC3986], section 6.2) > > > >is completely missing the point of the ladder. > > It was added due to a security review initiated by the IESG. > I think I wrote the actual text, but the suggestion for > the MUSTs didn't come from the authors, but from the security > expert. *grumble* If I had a dime for every time an IETF "security expert" screwed up an application protocol, I'd at least have a grande caramel machiatto to numb this headache. It is never a good idea to add requirements that make additional security-checking a non-compliant application. > The difference to the URI spec is not a good thing. But I disagree > with your explanation. Both XML Namespaces and RDF (which is > based on XML Namespaces) *require* character-by-character > comparison, for good reasons. No, they require strcmp comparison for certain procedures related to matching names. They cannot require implementations to ignore the equivalence of some URIs because that would change the meaning of the statements being made, particularly for RDF. > Otherwise, concepts such as > conformance to XML Namespaces or equivalence of RDF statements > would just hang in the air. No, they don't -- the processing algorithm does not change the meaning of the identifiers. It only defines minimal conformance criteria for implementations. RDF statements do not know the meaning of the URIs used to create those statements, nor do they know what URIs are equivalent, but not knowing that two URIs are equivalent does not change the fact that any statements made about the resource of one URI must also be valid for the resource of the other equivalent URI, since URIs cannot be equivalent if they do not both identify the same resource. In other words, there are no closed-world theories of equivalence that override the universality of URIs. The same applies to IRIs. > Security protocols are of course > another area of application where consistent behavior is > extremely important. "Sometimes it may match, sometimes not" > or "if you know all the schemes and protocols involved, the > server used on the other side, and the intent of the creator/ > maintainer of the resource for what to do about it in the future, > you'll get consistent results" are just sometimes not good enough. Security protocols make comparisons based on what is being secured, not based on some abstract theory. They are capable of defining that for themselves, consistently, and with respect to the resources being secured rather than one identifier used to access those resources. The IRI spec doesn't know enough about an application's needs to declare one form of comparison to be better than others. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 21:44:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04393 for ; Tue, 1 Feb 2005 21:44:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122YddY078979; Tue, 1 Feb 2005 18:34:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122Yd6I078978; Tue, 1 Feb 2005 18:34:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122YdBk078971 for ; Tue, 1 Feb 2005 18:34:39 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050202023434.VFNS4504.fed1rmmtao07.cox.net@[192.168.0.100]>; Tue, 1 Feb 2005 21:34:34 -0500 In-Reply-To: <55a1072e9398a9140f5c508b6ca0c78d@mac.com> References: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> <0b5370fb888a1d601c43673f18b17d6d@mac.com> <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> <55a1072e9398a9140f5c508b6ca0c78d@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: URI canonicalization Date: Tue, 1 Feb 2005 18:34:32 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 1, 2005, at 5:12 PM, Graham wrote: > On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: > >> There is no need to explain what "different ids" means -- any two >> URIs that are different identifiers will never compare as >> "equivalent", regardless of the comparison algorithm used. > > Pardon? If I use case sensitive ids (eg base64 style > "http://www.example.com/aBCde" and "http://www.example.com/aBCdE" are > different), and the client is case-insensitive, that's not going to > work. I meant regardless of the URI comparison algorithm used, as described in RFC3986. I wouldn't expect comparison based on number of "1" bits to work either. ....Roy From owner-atom-syntax@mail.imc.org Tue Feb 1 21:51:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04923 for ; Tue, 1 Feb 2005 21:51:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122eolG079808; Tue, 1 Feb 2005 18:40:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j122eopt079807; Tue, 1 Feb 2005 18:40:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j122enbH079799 for ; Tue, 1 Feb 2005 18:40:50 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j122drxC002707; Wed, 2 Feb 2005 02:39:58 GMT In-Reply-To: References: <3CA4AAEC-74A1-11D9-BBD7-003065EA6144@geckotribe.com> <0b5370fb888a1d601c43673f18b17d6d@mac.com> <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> <55a1072e9398a9140f5c508b6ca0c78d@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-155772822; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: URI canonicalization Date: Wed, 2 Feb 2005 02:39:51 +0000 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-9-155772822 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 2 Feb 2005, at 2:34 am, Roy T. Fielding wrote: > On Feb 1, 2005, at 5:12 PM, Graham wrote: >> On 2 Feb 2005, at 12:52 am, Roy T. Fielding wrote: >> >>> There is no need to explain what "different ids" means -- any two >>> URIs that are different identifiers will never compare as >>> "equivalent", regardless of the comparison algorithm used. >> >> Pardon? If I use case sensitive ids (eg base64 style >> "http://www.example.com/aBCde" and "http://www.example.com/aBCdE" are >> different), and the client is case-insensitive, that's not going to >> work. > > I meant regardless of the URI comparison algorithm used, as > described in RFC3986. I wouldn't expect comparison based on > number of "1" bits to work either. That RFC defines 4 different levels of equivalence. I'd be happy for the spec to say "Two different entries must have ids that are different under all provisions of RFC3986 Sect 6.2" This would also remove the last barrier to losing the canonicalization fluff. Graham --Apple-Mail-9-155772822 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAyMDIzOTUxWjAjBgkqhkiG9w0BCQQxFgQUDb2Fssdpcg1Timzi1BS7SgFx MroweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAxhz7tGW6TawDE6zjMjZJHgVQ O9Oe6OC8dqkfvjzSjO+BGxBEIhARnJ64zlXpFrISrh9QXUkOKmnsnyroiSwSS0ONndIE7vGLq2D5 RB/cq9XOopmJ1GFgH+uIC/3ZwjYnf/2kTauZgsAOGqp3CuDDry254dQZ+Rg3+PQVJ9lYcbZg/V2x CNBgWJlMnErfwvyxcLvm8SrRo1m6240bqRp4v95ztyuIf3jPLUZXwGKuTXr4KFvn7XeDftYBME18 MOQZF7BW0AVwhpr5iPyD0CP7qiGB/RP+tRXb+LpTNQeHj1XLzkznQxt6SJej3BQi2LfAjnb8vtbD Vd0kHqSE+Z7PygAAAAAAAA== --Apple-Mail-9-155772822-- From owner-atom-syntax@mail.imc.org Wed Feb 2 01:44:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05550 for ; Wed, 2 Feb 2005 01:44:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126VC52006134; Tue, 1 Feb 2005 22:31:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j126VCu2006133; Tue, 1 Feb 2005 22:31:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126VB5R006119 for ; Tue, 1 Feb 2005 22:31:11 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j126VBdt012319 for ; Tue, 1 Feb 2005 23:31:11 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9009WEU3Z88@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:31:11 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB9005H0U3YUK@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:31:11 -0700 (MST) Date: Tue, 01 Feb 2005 22:31:17 -0800 From: Tim Bray Subject: PaceFeedState to be updated? To: Atom Syntax Message-id: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT There was a huge amount of discussion around PaceFeedState, with input from our AD, and what smelled like converging language on the list. Is someone going to update the Pace to take that into account? -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 01:50:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06133 for ; Wed, 2 Feb 2005 01:50:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126WRwM006962; Tue, 1 Feb 2005 22:32:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j126WRdA006961; Tue, 1 Feb 2005 22:32:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126WQFx006900 for ; Tue, 1 Feb 2005 22:32:26 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j126WMVu007223 for ; Tue, 1 Feb 2005 23:32:22 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9009YMU5X88@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:32:22 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB9005H9U5WUK@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:32:21 -0700 (MST) Date: Tue, 01 Feb 2005 22:32:26 -0800 From: Tim Bray Subject: s/PaceFeedState/PaceFormatSecurity/ bleah To: Atom Syntax Message-id: <34620FA4-74E4-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Sorry, typo. I repeat: there was lots of discussion, good input, and what smelled like convergence. Someone needs to update PaceFormatSecurity. -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 01:57:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06714 for ; Wed, 2 Feb 2005 01:57:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126nr47016115; Tue, 1 Feb 2005 22:49:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j126nrS8016113; Tue, 1 Feb 2005 22:49:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126nqjG016103 for ; Tue, 1 Feb 2005 22:49:52 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j126nqdt020532 for ; Tue, 1 Feb 2005 23:49:52 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9008FEUZ3TG@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:49:52 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB9005M4UZ3UN@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:49:51 -0700 (MST) Date: Tue, 01 Feb 2005 22:49:57 -0800 From: Tim Bray Subject: Revised PaceIconAndImage, added PaceMultipleImages To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Having produced my own Atom feed has made me a supporter of this Pace; without getting too deep into it into their own elements, it changed the cardinality, allowing more than one in . I think this is probably a bad idea, but I'm 100% sure that it's wrong to mix up this with the (entirely separate) debate on whether to use instead of . So, I ripped it out of PaceIconAndImage and created a new PaceMultipleImages to suggest this. Third, along with these other changes, the Pace changed the aspect ratio from 2:1 to 1:1. Once again, this may be a good idea, but it needs discussion. But I kind of think this may have been a cut&paste typo, so I ripped it out but didn't create a new Pace, if someone really wants to change the Aspect ratio they should create a Pace. Having said all that, I'm +1 on PaceIconAndImage. I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, doesn't need those, YAGNI. -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 02:01:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08740 for ; Wed, 2 Feb 2005 02:01:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126pnu7016843; Tue, 1 Feb 2005 22:51:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j126pnuk016842; Tue, 1 Feb 2005 22:51:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j126pmp5016832 for ; Tue, 1 Feb 2005 22:51:48 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j126pmVu016032 for ; Tue, 1 Feb 2005 23:51:48 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IB9009I9V2CSI@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:51:48 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IB9005K7V29UK@mail.sun.net> for atom-syntax@imc.org; Tue, 01 Feb 2005 23:51:48 -0700 (MST) Date: Tue, 01 Feb 2005 22:51:50 -0800 From: Tim Bray Subject: PaceLinkEnclosure needs help To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT This Pace is a mess. I *think* its real purpose in life to suggest changing to . As it stands, it's highly likely to get drop-kicked by the chairs for being uncooked. If someone really wants this change, the Pace needs revision right now. -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 02:55:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12111 for ; Wed, 2 Feb 2005 02:55:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j127hG3E037466; Tue, 1 Feb 2005 23:43:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j127hGNP037464; Tue, 1 Feb 2005 23:43:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j127hF9K037257 for ; Tue, 1 Feb 2005 23:43:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 2 Feb 2005 20:43:31 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 02 Feb 2005 18:01:55 +1100 Subject: Re: URI canonicalization From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <7adb974bf2713e4f2d03d9c6f9a5e41b@gbiv.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 2/2/05 11:52 AM, "Roy T. Fielding" wrote: > any two > URIs that are different identifiers will never compare as > "equivalent", regardless of the comparison algorithm used. what about false negatives though? e. From owner-atom-syntax@mail.imc.org Wed Feb 2 02:55:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12165 for ; Wed, 2 Feb 2005 02:55:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j127hGrl037467; Tue, 1 Feb 2005 23:43:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j127hG3A037463; Tue, 1 Feb 2005 23:43:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j127hFm2037339 for ; Tue, 1 Feb 2005 23:43:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 2 Feb 2005 20:43:35 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 02 Feb 2005 18:33:35 +1100 Subject: Re: Revised PaceIconAndImage, added PaceMultipleImages From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j127hGm2037452 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 2/2/05 5:49 PM, "Tim Bray" wrote: > Having produced my own Atom feed has made me a supporter of this Pace; > without getting too deep into it while However, this Pace needed work; first of all, it was based on link > constructs, which no longer exist. So I revised it. I based it on Link Constructs because I was (a) trying to avoid spec bloat, and (b) being lazy. The Link Construct did provide for more than just a URI though -- there's @type, a title attribute (which could be used for the @alt), and (pushing it) @hreflang for those atom:image with text rendered. I'm happy to lose @hreflang, a user agent could use /feed/head/tagline instead of @title, and @type really isn't necessary because the set of image formats is pretty stable. So, +1. (with minor revisions ... change the section numbers to suit -05, and added cardinality to section "4.2 the atom:head element", otherwise the spec wouldn't say just where those elements could be used) > Second, along with turning Icon and Image from into their own > elements, it changed the cardinality, allowing more than one > in . I think this is probably a bad idea, but > I'm 100% sure that it's wrong to mix up this with the (entirely > separate) debate on whether to use instead of . So, I > ripped it out of PaceIconAndImage and created a new PaceMultipleImages > to suggest this. +1. I wish more paces were decoupled. (makes note to self) > Third, along with these other changes, the Pace changed the > aspect ratio from 2:1 to 1:1. That must have been a copy/pasto. I know I set the atom:icon aspect ratio to 1:1, and thought I kept the 2:1 aspect ratio for atom:image. > Once again, this may be a > good idea, but it needs discussion. But I kind of think this may have > been a cut&paste typo, so I ripped it out but didn't create a new Pace, > if someone really wants to change the Aspect ratio they should create a > Pace. Yep, copy/pasto ... no, wait ... it actually said: >> === 4.2.y atom:image Element === >> >>  The "atom:icon" element is a Link construct that conveys a URI to an >>  image resource which provides visual identification for a feed. The >>  image SHOULD have an aspect ratio of 2 (horizontal) to 1 (vertical). 2:1, but I did have a copy/pasto brainfart with the name of the element in the prose of the section. > Having said all that, I'm +1 on PaceIconAndImage. +1 > I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, > doesn't need those, YAGNI. fair enough - there's been enough flack over multiple content. e. From owner-atom-syntax@mail.imc.org Wed Feb 2 03:43:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16612 for ; Wed, 2 Feb 2005 03:43:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j128VP6n057482; Wed, 2 Feb 2005 00:31:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j128VPN1057481; Wed, 2 Feb 2005 00:31:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j128VNR6057461 for ; Wed, 2 Feb 2005 00:31:24 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwFuz-0000YG-Ba; Wed, 02 Feb 2005 08:31:21 +0000 Message-ID: <42008FD6.6090708@franklinmint.fm> Date: Wed, 02 Feb 2005 03:31:18 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceFormatSecurity to be updated? References: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> In-Reply-To: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > There was a huge amount of discussion around PaceFormatSecurity, with > input from our AD, and what smelled like converging language on the > list. Is someone going to update the Pace to take that into account? > -Tim > --------------------------- 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 types of attack. Every Atom Processor should carefully consider their handling of every type of element when processing incoming (X)HTML in Atom documents. See the security sections of RFC 2854 and HTML 4.01 for some guidance on many types of attack. Atom Processors should pay particular attention to the security of the IMG, SCRIPT, EMBED, OBJECT, FRAME, FRAMESET, IFRAME, META, and LINK elements, but other elements may also have negative security properties. (X)HTML can either directly contain or indirectly reference executable content. 10.1.1 URIs Atom Processors handle URIs. See Section 7 of RFC 3986. 10.1.2 IRIs Atom Processors handle IRIs. See Section 8 of RFC 3987. --------------------------- Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 07:38:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00815 for ; Wed, 2 Feb 2005 07:38:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12CQHfc045736; Wed, 2 Feb 2005 04:26:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12CQH1b045735; Wed, 2 Feb 2005 04:26:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12CQGq2045651 for ; Wed, 2 Feb 2005 04:26:17 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Feb 2005 12:26:04 -0000 Received: from p50824A45.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.74.69) by mail.gmx.net (mp027) with SMTP; 02 Feb 2005 13:26:04 +0100 X-Authenticated: #1915285 Message-ID: <4200C6DC.5010208@gmx.de> Date: Wed, 02 Feb 2005 13:26:04 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Trial format-05 atom feed References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 > http://www.tbray.org/ongoing/ongoing.atom Same here (). Maybe it would make sense to collect URLs of test feeds on a Wiki page? > ... Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Feb 2 07:42:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01018 for ; Wed, 2 Feb 2005 07:42:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12CTgZj046807; Wed, 2 Feb 2005 04:29:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12CTgn8046806; Wed, 2 Feb 2005 04:29:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12CTfS7046793 for ; Wed, 2 Feb 2005 04:29:41 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j12CTckc027253; Wed, 2 Feb 2005 07:29:38 -0500 (EST) Message-ID: <4200C7B3.8070900@intertwingly.net> Date: Wed, 02 Feb 2005 07:29:39 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: Trial format-05 atom feed References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 > http://www.tbray.org/ongoing/ongoing.atom the xmlns and version indicate format-04. > I guess the only thing that's mildly interesting is that some entries > have and others have depending on whether the whole > thing's there. -Tim Just curious, why is the on the same line as <entry>? A blank line before every entry might also improve readability. > PS: if you open that URL in FireFox (on OS X anyhow), and FireFox asks > you what program you'd like to open it in, do not (repeat NOT) tell > FireFox to open it in FireFox. Trust me on this. Suggestion: try view-source:http://www.tbray.org/ongoing/ongoing.atom No, it is not a registered uri scheme, but it seems to be a defacto standard. - Sam Ruby P.S. w.r.t. the version attribute, I still believe that YAGNI. But if it is to remain, I hope that the final version is mercifully short. From owner-atom-syntax@mail.imc.org Wed Feb 2 07:58:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01238 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 07:58:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12C9Ucb039293; Wed, 2 Feb 2005 04:09:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12C9Ud0039292; Wed, 2 Feb 2005 04:09:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.sdf1.net (anakim.1meg.golden.net [216.75.172.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12C9TLn039246 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 04:09:30 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [192.168.1.101] (Quebec-HSE-ppp3615824.sympatico.ca [65.93.205.143]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.sdf1.net (Postfix) with ESMTP id BED0DF705; Wed, 2 Feb 2005 07:09:22 -0500 (EST) In-Reply-To: <EA1304B4-74E6-11D9-968C-000A95A51C9E@sun.com> References: <EA1304B4-74E6-11D9-968C-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7e6b775268e7362e5025170861c96c94@sdf1.net> Content-Transfer-Encoding: 7bit Cc: Tim Bray <tim.bray@sun.com>, August Trometer <BlueGus@mac.com> From: Ray Slakinski <kier@sdf1.net> Subject: Re: PaceLinkEnclosure needs help Date: Wed, 2 Feb 2005 07:09:24 -0500 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 obvious, but rel could be used to specify alternate, torrent, quality and things like that, and allow future expansion without breaking when we do. [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net If God had meant for us to be in the Army, we would have been born with green, baggy skin. On 2-Feb-05, at 1:51 AM, Tim Bray wrote: > > This Pace is a mess. I *think* its real purpose in life to suggest > changing <atom:enclosure> to <atom:attachment>. As it stands, it's > highly likely to get drop-kicked by the chairs for being uncooked. If > someone really wants this change, the Pace needs revision right now. > -Tim > From owner-atom-syntax@mail.imc.org Wed Feb 2 08:42:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02548 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 08:42:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12DXOLj068999; Wed, 2 Feb 2005 05:33:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12DXOI7068998; Wed, 2 Feb 2005 05:33:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12DXMJN068942 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 05:33:23 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 3 Feb 2005 02:33:38 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 00:32:48 +1100 Subject: Re: Trial format-05 atom feed From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2721B0.45C45%eric.scheid@ironclad.net.au> In-Reply-To: <4200C7B3.8070900@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 2/2/05 11:29 PM, "Sam Ruby" <rubys@intertwingly.net> wrote: >> http://www.tbray.org/ongoing/ongoing.atom > > the xmlns and version indicate format-04. -05 is functionally equivalent to -04 (sans errors) e. From owner-atom-syntax@mail.imc.org Wed Feb 2 10:02:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12173 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:02:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12EorI8074316; Wed, 2 Feb 2005 06:50:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12EorwW074315; Wed, 2 Feb 2005 06:50:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Eoq4j074309 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 06:50:52 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j12Eof4R003299; Wed, 2 Feb 2005 09:50:41 -0500 (EST) Message-ID: <4200E8C2.6010800@intertwingly.net> Date: Wed, 02 Feb 2005 09:50:42 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Trial format-05 atom feed References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C6DC.5010208@gmx.de> In-Reply-To: <4200C6DC.5010208@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 >> http://www.tbray.org/ongoing/ongoing.atom > > Same here (<http://greenbytes.de/tech/webdav/webdav.atom>). I find your use of opaquelocktokens intriguing. My reading of the spec is that opaquelocktokens are sequences of 8, 4, 4, 12 hex digits, separated by dashes, optionally followed by a path. In place of a path, I see what appears to be a timestamp. Can somebody cite a reference which permits such uris? - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Feb 2 10:23:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16002 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:23:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FE4VP076521; Wed, 2 Feb 2005 07:14:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FE4Z2076520; Wed, 2 Feb 2005 07:14:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12FE3LE076511 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:14:03 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Feb 2005 15:13:57 -0000 Received: from p50824A45.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.74.69) by mail.gmx.net (mp013) with SMTP; 02 Feb 2005 16:13:57 +0100 X-Authenticated: #1915285 Message-ID: <4200EE34.5050302@gmx.de> Date: Wed, 02 Feb 2005 16:13:56 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Trial format-05 atom feed References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C6DC.5010208@gmx.de> <4200E8C2.6010800@intertwingly.net> In-Reply-To: <4200E8C2.6010800@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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. Check it out at >>> http://www.tbray.org/ongoing/ongoing.atom >> >> >> Same here (<http://greenbytes.de/tech/webdav/webdav.atom>). > > > I find your use of opaquelocktokens intriguing. My reading of the spec > is that opaquelocktokens are sequences of 8, 4, 4, 12 hex digits, > separated by dashes, optionally followed by a path. > > In place of a path, I see what appears to be a timestamp. Can somebody > cite a reference which permits such uris? The timestamps I am using are legal path components, according to RFC2068, section 3.2.1 (which RCF2518's definition for the "opaquelocktoken" scheme refers to). Or am I missing something? Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Feb 2 10:29:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16808 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:29:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FIr45076798; Wed, 2 Feb 2005 07:18:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FIrPv076797; Wed, 2 Feb 2005 07:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FIqSe076782 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:18:52 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020215184201200g5ieke>; Wed, 2 Feb 2005 15:18:42 +0000 Date: Wed, 2 Feb 2005 08:18:41 -0700 Subject: Re: PaceFormatSecurity to be updated? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42008FD6.6090708@franklinmint.fm> Message-Id: <B8DFC24C-752D-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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. From owner-atom-syntax@mail.imc.org Wed Feb 2 10:40:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18259 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:40:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FRfIj077436; Wed, 2 Feb 2005 07:27:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FRfIP077435; Wed, 2 Feb 2005 07:27:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FRfw4077428 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:27:41 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j12FReVu013459 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:27:40 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA009JRIY4A9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:27:40 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA000A2IY38A@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:27:40 -0700 (MST) Date: Wed, 02 Feb 2005 07:27:41 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Trial format-05 atom feed In-reply-to: <4200C7B3.8070900@intertwingly.net> To: Sam Ruby <rubys@intertwingly.net> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <FAAE2042-752E-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C7B3.8070900@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT 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 attribute, I still believe that YAGNI. But > if it is to remain, I hope that the final version is mercifully short. I would be +1 on removing the version attribute. Someone do a one-line Pace? -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 10:42:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18596 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:42:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FWVp5077770; Wed, 2 Feb 2005 07:32:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FWVl2077769; Wed, 2 Feb 2005 07:32:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FWUiA077759 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:32:30 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j12FWUVu017887 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:32:30 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA008SWJ65HR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:32:30 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA000BLJ658A@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:32:29 -0700 (MST) Date: Wed, 02 Feb 2005 07:32:35 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Trial format-05 atom feed In-reply-to: <4200C6DC.5010208@gmx.de> To: Julian Reschke <julian.reschke@gmx.de> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <A9E86B34-752F-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C6DC.5010208@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 4:26 AM, Julian Reschke wrote: > Same here (<http://greenbytes.de/tech/webdav/webdav.atom>). The empty summaries seem to me to be legal but surprising. Hmm... the "summary" text is in the titles. Kind of surprising but I guess it works. You could just have easily have had empty titles and the text in the summary. -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 10:50:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19743 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:50:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FcPMX078546; Wed, 2 Feb 2005 07:38:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FcPRt078545; Wed, 2 Feb 2005 07:38:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FcOUn078536 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:38:24 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j12Fb8VO014987 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 15:37:14 GMT Mime-Version: 1.0 (Apple Message framework v619.2) To: Atom Syntax <atom-syntax@imc.org> Message-Id: <71234c9ab7c316582d9da9c077b76457@mac.com> Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1-202411213; protocol="application/pkcs7-signature" From: Graham <dtcd@mac.com> Subject: tagline -> subtitle Date: Wed, 2 Feb 2005 15:37:09 +0000 X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> --Apple-Mail-1-202411213 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Any chance of renaming atom:tagline to atom:subtitle? The two sample feeds posted today have the taglines "ongoing fragmented essay by Tim Bray" and "WebDAV related news". Aren't taglines meant to be funny or catchy or clever? The relevant definitions from dictionary.com are: tagline: An often repeated phrase associated with an individual, organization, or commercial product; a slogan. subtitle: A secondary, usually explanatory title, as of a literary work. The second seems much broader and more useful, and there's nothing stopping you using a slogan as subtitle. Graham --Apple-Mail-1-202411213 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAyMTUzNzEwWjAjBgkqhkiG9w0BCQQxFgQU5urJTCvNubSmaXM5A+WpK9Pv a7UweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAiDitcEo5j7wD/Xy/Wk5w0Ahz 5VZGP6QnBDNe9kc6HdZ6C4S25lP0SiiChIbhcs73a2LFJrC7UJCzLMjJ+Nm7xD70edar6QaRJoBN 08Td9Y9jCl2x07p1t6kfGztHpmEB7ZzCppAQzl8QTKYb7GqYWwQgwRmW/X5GFHE52W/sxIbbW5HJ +fWb56JvXy53eswJ+hw/3vRdFp2kuEfjgygZv3jav/2OY98IiD3AOyWyRtim1fr9tYjXu6haFfKr mlJqZrc9/j3DALwbssirAuxlJWGfO5/RMprZT+KeoojlV9KkGYOuB+/LxE8Z5/sr07c9vjjy9ozy xYlgCM8FHMgQvgAAAAAAAA== --Apple-Mail-1-202411213-- From owner-atom-syntax@mail.imc.org Wed Feb 2 10:52:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19960 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:52:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Fk5D1079263; Wed, 2 Feb 2005 07:46:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Fk5OX079262; Wed, 2 Feb 2005 07:46:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12Fk40A079253 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:46:04 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Feb 2005 15:45:58 -0000 Received: from p50824A45.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.74.69) by mail.gmx.net (mp028) with SMTP; 02 Feb 2005 16:45:58 +0100 X-Authenticated: #1915285 Message-ID: <4200F5B3.1020804@gmx.de> Date: Wed, 02 Feb 2005 16:45:55 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Trial format-05 atom feed References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C6DC.5010208@gmx.de> <A9E86B34-752F-11D9-968C-000A95A51C9E@sun.com> In-Reply-To: <A9E86B34-752F-11D9-968C-000A95A51C9E@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Feb 2, 2005, at 4:26 AM, Julian Reschke wrote: > >> Same here (<http://greenbytes.de/tech/webdav/webdav.atom>). > > > The empty summaries seem to me to be legal but surprising. > > Hmm... the "summary" text is in the titles. Kind of surprising but I > guess it works. You could just have easily have had empty titles and > the text in the summary. -Tim Good catch -- that was a bug in my conversion code. Fixed. Best regards, Julian -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Feb 2 10:56:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20449 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 10:56:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FkNnK079303; Wed, 2 Feb 2005 07:46:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12FkNgQ079302; Wed, 2 Feb 2005 07:46:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12FkM7B079296 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 07:46:22 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j12FkMdt028234 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:46:22 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA009WRJT9H4@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:46:22 -0700 (MST) Received: from [10.12.0.41] ([65.89.25.206]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA000GXJT88A@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 08:46:21 -0700 (MST) Date: Wed, 02 Feb 2005 07:46:27 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceFormatSecurity to be updated? In-reply-to: <42008FD6.6090708@franklinmint.fm> To: Robert Sayre <mint@franklinmint.fm> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <99BDC320-7531-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> <42008FD6.6090708@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 12:31 AM, Robert Sayre wrote: > 10.1 HTML and XHTML Content I've dressed this up as PaceSecuritySection: http://www.intertwingly.net/wiki/pie/PaceSecuritySection From owner-atom-syntax@mail.imc.org Wed Feb 2 11:17:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23075 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:17:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12G7HfC081448; Wed, 2 Feb 2005 08:07:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12G7Hc5081447; Wed, 2 Feb 2005 08:07:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12G7G06081439 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:07:16 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so113661rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 08:07:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=O0dHWPNAn36RfuvJhsg5fuERPKvEuMrYaWCnaidRY/ORTuI+B6vpiS6p8u0iy9psLSkaPAgsDm+ZVq3AJXdjAEsW7KSylYNMW0GzLlHDY3G7jfwob74d8+gLce1kJgu1pmPeJgZ9B/nQ2WEB8tAgyH9emY5XhVrdGoVPR9IsaRU= Received: by 10.38.149.2 with SMTP id w2mr8785rnd; Wed, 02 Feb 2005 08:07:15 -0800 (PST) Received: by 10.38.151.18 with HTTP; Wed, 2 Feb 2005 08:07:15 -0800 (PST) Message-ID: <3f1451f505020208071639d057@mail.gmail.com> Date: Wed, 2 Feb 2005 11:07:15 -0500 From: Joe Gregorio <joe.gregorio@gmail.com> Reply-To: Joe Gregorio <joe.gregorio@gmail.com> To: Robert Sayre <mint@franklinmint.fm> Subject: Re: PaceFormatSecurity to be updated? Cc: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org> In-Reply-To: <42008FD6.6090708@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> <42008FD6.6090708@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I had updated PaceFormatSecuruty based on feedback, removing all the proscriptive prose about removing elements and just pointing out potential security problems. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Feb 2 11:18:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23206 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:18:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GA9i1081651; Wed, 2 Feb 2005 08:10:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GA9mx081650; Wed, 2 Feb 2005 08:10:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GA81j081640 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:10:09 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050202161003016004jtjde>; Wed, 2 Feb 2005 16:10:03 +0000 Date: Wed, 2 Feb 2005 09:10:02 -0700 Subject: Re: Revised PaceIconAndImage, added PaceMultipleImages Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <BE26CD7F.45B71%eric.scheid@ironclad.net.au> Message-Id: <E4F2FF1E-7534-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wednesday, February 2, 2005, at 12:33 AM, Eric Scheid wrote: > On 2/2/05 5:49 PM, "Tim Bray" <Tim.Bray@Sun.COM> wrote: >> Having produced my own Atom feed has made me a supporter of this Pace; >> without getting too deep into it <link rel="self" feels quite >> sensible, >> while <link rel="icon" feels stupid. > +1 +1 > ... and @type really isn't necessary because the set of image formats > is pretty stable. > So, +1. Yeah, if you want a hint at the image type, check the filename--it won't always end in a recognized ".gif", ".jpeg", ".png", etc., but should often enough. >> ...it changed the cardinality, allowing more than one >> <atom:image> in <atom:head>. I think this is probably a bad idea, but Agreed. At the feed level, one image is plenty. If entries get images (see below), then multiple images could be useful in some limited cases, but it would probably be a really slim edge case. If someone wants multiple images in an entry, they can use (X)HTML <img />. With multiple images, it's likely the publisher will want that level of control over their presentation anyway. >> Having said all that, I'm +1 on PaceIconAndImage. > +1 +1 Three questions (and my opinions--and reasoning (principled reasoning?)): 1) Should entries be able to have images? (Yes. Entries COULD include images using (X)HTML's <img /> elements, but atom:image would give consuming applications much greater flexibility in how they arrange their display. If publishers want an image displayed in a particular manner, they can use (X)HTML's <img /> element. I would think this would be a great way to publish images from camera phones, for example--snap off an image; add a little text; post it. Then why isn't everyone doing it that way using RSS 1.0's <image /> or RSS 2's <enclosure />? ...uh, because they haven't had that "Aha!" moment yet!?) 1a) Should we recommend an aspect ratio for entry images? (No. That would be an unnatural constraint. People are going to be posting source images of all shapes, and (almost) forcing the images into one shape woudl be too heavy handed.) 2) Should entries be able to have icons? (Hmm...I'm torn. I can imagine it being put to good use, but I doubt it would be widely used. I'd be happy either way.) 3) Should images have a @title or @alt or some such thing? (If entries get images, then yes--cramming that in summary or some such place feels sloppy. If only feeds have images, then it's not so important.) From owner-atom-syntax@mail.imc.org Wed Feb 2 11:24:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23685 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:24:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GFXkW082152; Wed, 2 Feb 2005 08:15:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GFWfA082151; Wed, 2 Feb 2005 08:15:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GFWiI082132 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:15:32 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050202161527016004ddcie>; Wed, 2 Feb 2005 16:15:27 +0000 Date: Wed, 2 Feb 2005 09:15:26 -0700 Subject: Re: PaceLinkEnclosure needs help Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <7e6b775268e7362e5025170861c96c94@sdf1.net> Message-Id: <A600909E-7535-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wednesday, February 2, 2005, at 05:09 AM, Ray Slakinski wrote: > url, type, and length is pretty obvious, but rel could be used to > specify alternate, torrent, quality and things like that, and allow > future expansion without breaking when we do. > If the content being pointed to is an alternate of the entry content, <link rel="alternate" ... /> is probably better--using <attachment>) for that would duplicate functionality. @rel probably isn't the best name for the other values you suggest. Off the top of my head, I'd recommend allowing extension child elements or extension attributes to specify such things. From owner-atom-syntax@mail.imc.org Wed Feb 2 11:27:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24111 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:27:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GIv0Y082439; Wed, 2 Feb 2005 08:18:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GIvQa082438; Wed, 2 Feb 2005 08:18:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GIssr082430; Wed, 2 Feb 2005 08:18:54 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06200701be2617ba484e@[10.20.30.249]> In-Reply-To: <41FFEF0D.1090200@gmx.de> References: <41FFEF0D.1090200@gmx.de> Date: Tue, 1 Feb 2005 21:40:38 -0800 To: Julian Reschke <julian.reschke@gmx.de>, Atom Syntax <atom-syntax@imc.org> From: Paul Hoffman <phoffman@imc.org> Subject: Re: Format spec vs Protocol spec Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 10:05 PM +0100 2/1/05, Julian Reschke wrote: >As far as I understand the IETF publication process, this means that >draft-ietf-atompub-format can't be published until the protocol spec >is ready as well. Others have said we can and should remove the dependency, which is fine. Wearing my nitpicky-IETF-geek hat, I would point out that specs with dangling dependencies can be made standards without clearing the dependencies; they simply can't be published as RFCs with them. There are dozens (possibly over a hundred) IETF standards-track documents that have not yet been published as RFCs for a variety of reasons, many of them quite lame. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Feb 2 11:28:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24266 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:28:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GIAfs082380; Wed, 2 Feb 2005 08:18:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GIADH082379; Wed, 2 Feb 2005 08:18:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12GI5XW082366 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:18:05 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 02 Feb 2005 16:17:59 -0000 Received: from p50824A45.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.74.69) by mail.gmx.net (mp026) with SMTP; 02 Feb 2005 17:17:59 +0100 X-Authenticated: #1915285 Message-ID: <4200FD36.6040004@gmx.de> Date: Wed, 02 Feb 2005 17:17:58 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: tagline -> subtitle References: <71234c9ab7c316582d9da9c077b76457@mac.com> In-Reply-To: <71234c9ab7c316582d9da9c077b76457@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Graham wrote: > Any chance of renaming atom:tagline to atom:subtitle? The two sample > feeds posted today have the taglines "ongoing fragmented essay by Tim > Bray" and "WebDAV related news". Aren't taglines meant to be funny or > catchy or clever? > > The relevant definitions from dictionary.com are: > tagline: An often repeated phrase associated with an individual, > organization, or commercial product; a slogan. > subtitle: A secondary, usually explanatory title, as of a literary work. > > The second seems much broader and more useful, and there's nothing > stopping you using a slogan as subtitle. +1 -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Wed Feb 2 11:31:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24737 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:31:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GMOjw082760; Wed, 2 Feb 2005 08:22:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GMORf082759; Wed, 2 Feb 2005 08:22:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GMNx0082752 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:22:23 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j12GMLCh011429; Wed, 2 Feb 2005 11:22:21 -0500 (EST) Message-ID: <4200FE3E.3070002@intertwingly.net> Date: Wed, 02 Feb 2005 11:22:22 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray <Tim.Bray@Sun.COM> CC: Atom Syntax <atom-syntax@imc.org> Subject: PaceRemoveVersionAttr (was: Trial format-05 atom feed) References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C7B3.8070900@intertwingly.net> <FAAE2042-752E-11D9-968C-000A95A51C9E@sun.com> In-Reply-To: <FAAE2042-752E-11D9-968C-000A95A51C9E@sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tim Bray wrote: > >> P.S. w.r.t. the version attribute, I still believe that YAGNI. But >> if it is to remain, I hope that the final version is mercifully short. > > I would be +1 on removing the version attribute. Someone do a one-line > Pace? -Tim Done: http://www.intertwingly.net/wiki/pie/PaceRemoveVersionAttr Note: I added some questions at the bottom. Much to my surprise, scanning the current document, I don't see any "must ignore" text. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Feb 2 11:48:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26979 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:48:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GcrUC083840; Wed, 2 Feb 2005 08:38:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GcrG9083839; Wed, 2 Feb 2005 08:38:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GcqsR083831 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:38:52 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so125396rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 08:38:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mTZuFgCkCzszX5ZgGNfa5fMHJR17+SG3A6Ajq+NEzFEM7+n/i0wRiWmYK7K2dpF0q94ocbs8EAp20g8nisgcJh1zc4vbWIknaiWhxgXAdbaAfR2Dqh8A33323YA/LjfakM8iGWpO4GdK/e9IsUV2SoY/v8ZFcaJuJHXFwyLyh/o= Received: by 10.38.125.66 with SMTP id x66mr256196rnc; Wed, 02 Feb 2005 08:38:48 -0800 (PST) Received: by 10.38.151.18 with HTTP; Wed, 2 Feb 2005 08:38:48 -0800 (PST) Message-ID: <3f1451f5050202083879651457@mail.gmail.com> Date: Wed, 2 Feb 2005 11:38:48 -0500 From: Joe Gregorio <joe.gregorio@gmail.com> Reply-To: Joe Gregorio <joe.gregorio@gmail.com> To: Robert Sayre <mint@franklinmint.fm> Subject: Re: PaceFormatSecurity to be updated? Cc: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org> In-Reply-To: <42008FD6.6090708@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> <42008FD6.6090708@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre <mint@franklinmint.fm> 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 types of attack. Every Atom Processor > should carefully consider their handling of every type of element when > processing incoming (X)HTML in Atom documents. See the security sections > of RFC 2854 and HTML 4.01 for some guidance on many types of attack. As I've stated before, referencing the security sections of these two documents will not be helpful to an implementer. Also, you have dropped all references to CSS. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Feb 2 11:50:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27446 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:50:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Gh1GP084068; Wed, 2 Feb 2005 08:43:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Gh1Pv084067; Wed, 2 Feb 2005 08:43:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Gh1YH084057 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:43:01 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 42388 invoked by uid 17064); 2 Feb 2005 16:42:51 -0000 Received: from unknown (HELO [10.20.30.17]) ([195.101.242.1]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 2 Feb 2005 16:42:51 -0000 In-Reply-To: <A6FE8ADE-74E6-11D9-968C-000A95A51C9E@sun.com> References: <A6FE8ADE-74E6-11D9-968C-000A95A51C9E@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <cdd3598219b94e8dedebd13f32d80133@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Henry Story <henry.story@bblfish.net> Subject: Re: Revised PaceIconAndImage, added PaceMultipleImages Date: Wed, 2 Feb 2005 17:42:49 +0100 To: Tim Bray <Tim.Bray@Sun.COM> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 subclass of an Entry. Of course if they did not make it into the spec it would be easy to add them as extensions. So the effort in speccing this would not be wasted. You may want to consider that an icon of an image is also related somehow to the original. In the feeds mentioned above, clicking on the icon brings you to a the original image the icon is a representation of. In one case [1] it occurred to me that have been more intuitive to have clicking on the image bring up a video. Henry Story [1] http://www.bblfish.net/blog/page3.html#25 On 2 Feb 2005, at 07:49, Tim Bray wrote: > > Having produced my own Atom feed has made me a supporter of this Pace; > without getting too deep into it <link rel="self" feels quite > sensible, while <link rel="icon" feels stupid. > > However, this Pace needed work; first of all, it was based on link > constructs, which no longer exist. So I revised it. > > Second, along with turning Icon and Image from <link> into their own > elements, it changed the cardinality, allowing more than one > <atom:image> in <atom:head>. I think this is probably a bad idea, but > I'm 100% sure that it's wrong to mix up this with the (entirely > separate) debate on whether to use <image> instead of <link>. So, I > ripped it out of PaceIconAndImage and created a new PaceMultipleImages > to suggest this. > > Third, along with these other changes, the Pace changed the > <atom:image> aspect ratio from 2:1 to 1:1. Once again, this may be a > good idea, but it needs discussion. But I kind of think this may have > been a cut&paste typo, so I ripped it out but didn't create a new > Pace, if someone really wants to change the Aspect ratio they should > create a Pace. > > Having said all that, I'm +1 on PaceIconAndImage. > > I'm -1 on PaceMultipleImages, this is an experimental feature, Atom, > doesn't need those, YAGNI. > -Tim > From owner-atom-syntax@mail.imc.org Wed Feb 2 11:54:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28635 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:54:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GmQXI084506; Wed, 2 Feb 2005 08:48:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GmQg8084505; Wed, 2 Feb 2005 08:48:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GmOoL084498 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:48:25 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j12GmOVu023641 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:48:24 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA0091ZMOOA9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 09:48:24 -0700 (MST) Received: from [10.12.0.13] ([129.150.29.58]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA0069IMON44@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 09:48:24 -0700 (MST) Date: Wed, 02 Feb 2005 08:48:29 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceRemoveVersionAttr (was: Trial format-05 atom feed) In-reply-to: <4200FE3E.3070002@intertwingly.net> To: Sam Ruby <rubys@intertwingly.net> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <445B4A18-753A-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C7B3.8070900@intertwingly.net> <FAAE2042-752E-11D9-968C-000A95A51C9E@sun.com> <4200FE3E.3070002@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT 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 :) From owner-atom-syntax@mail.imc.org Wed Feb 2 11:57:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29012 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:57:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GpSRS084788; Wed, 2 Feb 2005 08:51:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12GpSBS084787; Wed, 2 Feb 2005 08:51:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GpRIA084769 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:51:27 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 13606 invoked by uid 10); 2 Feb 2005 16:51:10 -0000 Received: (vexira-qq 13593-89746E4 invoked from network) 02 Feb 2005 17:51:09 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender <fora@annevankesteren.nl>) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 2 Feb 2005 16:51:09 -0000 Message-ID: <42010502.2000604@annevankesteren.nl> Date: Wed, 02 Feb 2005 17:51:14 +0100 From: Anne van Kesteren <fora@annevankesteren.nl> User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceRemoveVersionAttr References: <B6CE29FA-74BF-11D9-968C-000A95A51C9E@sun.com> <4200C7B3.8070900@intertwingly.net> <FAAE2042-752E-11D9-968C-000A95A51C9E@sun.com> <4200FE3E.3070002@intertwingly.net> In-Reply-To: <4200FE3E.3070002@intertwingly.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.5; VDF: 6.29.0.52; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Done: http://www.intertwingly.net/wiki/pie/PaceRemoveVersionAttr > > Note: I added some questions at the bottom. Much to my surprise, > scanning the current document, I don't see any "must ignore" text. I really like the ideas about specifying how Atom should be both forward and backwards compatible and that if a new specification can not comply to that, a new namespace should be used. -- Anne van Kesteren <http://annevankesteren.nl/> From owner-atom-syntax@mail.imc.org Wed Feb 2 11:59:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29150 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:59:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Gn7tF084570; Wed, 2 Feb 2005 08:49:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Gn7GT084569; Wed, 2 Feb 2005 08:49:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Gn7KF084562 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:49:07 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 50215 invoked by uid 17064); 2 Feb 2005 16:49:07 -0000 Received: from unknown (HELO [10.20.30.17]) ([195.101.242.1]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 2 Feb 2005 16:49:07 -0000 In-Reply-To: <4200FD36.6040004@gmx.de> References: <71234c9ab7c316582d9da9c077b76457@mac.com> <4200FD36.6040004@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <bda7fea5bf630212e9dc99fb16e6ffe1@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Henry Story <henry.story@bblfish.net> Subject: Re: tagline -> subtitle Date: Wed, 2 Feb 2005 17:49:03 +0100 To: Graham <dtcd@mac.com> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 pace, that a Feed is a structure that is a subclass of the Entry structure. And then we will really cut the length of the spec down to its core. Henry Story On 2 Feb 2005, at 17:17, Julian Reschke wrote: > Graham wrote: >> Any chance of renaming atom:tagline to atom:subtitle? The two sample >> feeds posted today have the taglines "ongoing fragmented essay by Tim >> Bray" and "WebDAV related news". Aren't taglines meant to be funny or >> catchy or clever? >> The relevant definitions from dictionary.com are: >> tagline: An often repeated phrase associated with an individual, >> organization, or commercial product; a slogan. >> subtitle: A secondary, usually explanatory title, as of a literary >> work. >> The second seems much broader and more useful, and there's nothing >> stopping you using a slogan as subtitle. > > +1 From owner-atom-syntax@mail.imc.org Wed Feb 2 11:59:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29188 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 11:59:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12GriON084955; Wed, 2 Feb 2005 08:53:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Grinw084954; Wed, 2 Feb 2005 08:53:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Grhgp084946 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 08:53:43 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwNl1-0005SR-5U; Wed, 02 Feb 2005 16:53:35 +0000 Message-ID: <4201058D.8050502@franklinmint.fm> Date: Wed, 02 Feb 2005 11:53:33 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Gregorio <joe.gregorio@gmail.com> CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceFormatSecurity to be updated? References: <0B1893E6-74E4-11D9-968C-000A95A51C9E@sun.com> <42008FD6.6090708@franklinmint.fm> <3f1451f5050202083879651457@mail.gmail.com> In-Reply-To: <3f1451f5050202083879651457@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Joe Gregorio wrote: > On Wed, 02 Feb 2005 03:31:18 -0500, Robert Sayre <mint@franklinmint.fm> 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 types of attack. Every Atom Processor >>should carefully consider their handling of every type of element when >>processing incoming (X)HTML in Atom documents. See the security sections >>of RFC 2854 and HTML 4.01 for some guidance on many types of attack. > > > As I've stated before, referencing the security sections of these two > documents will not be helpful to an implementer. Yes, you've stated that before. Two paragraphs on HTML security is still laughably inadequate, only they're in the wrong document, where they won't receive adequate review. What implementors *would* find helpful is a document covering these subjects authored by experts in HTML layout engines, JavaScript interpreters, and CSS. Anyway, the Paces don't have opposing requirements, and our AD has told us what to write. I'm not sure why we're wasting WG time on this. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 12:18:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01098 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:18:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12H71fC085839; Wed, 2 Feb 2005 09:07:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12H71Dm085838; Wed, 2 Feb 2005 09:07:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12H6u79085829 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:06:56 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 70245 invoked by uid 17064); 2 Feb 2005 17:06:56 -0000 Received: from unknown (HELO [10.20.30.17]) ([195.101.242.1]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 2 Feb 2005 17:06:56 -0000 In-Reply-To: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5999a03226f1d4e75597a43834a9843e@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Henry Story <henry.story@bblfish.net> Subject: Re: PaceExtendingAtom Date: Wed, 2 Feb 2005 18:06:53 +0100 To: Tim Bray <tbray@textuality.com> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit -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 and an OWL ontology. This would be helpful and very useful. PaceExtendingAtom as it currently is stated is restrictive without being useful. Henry Story On 13 Jan 2005, at 19:27, Tim Bray wrote: > > +1 > > I wrote it and I still think it's necessary as a bare-minimum measure. > -Tim > From owner-atom-syntax@mail.imc.org Wed Feb 2 12:21:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01341 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:21:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12H98mm085959; Wed, 2 Feb 2005 09:09:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12H98RP085958; Wed, 2 Feb 2005 09:09:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12H98gZ085950 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:09:08 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050202170902015009nikie>; Wed, 2 Feb 2005 17:09:03 +0000 Date: Wed, 2 Feb 2005 10:09:02 -0700 Subject: Re: tagline -> subtitle Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <bda7fea5bf630212e9dc99fb16e6ffe1@bblfish.net> Message-Id: <2309DBF4-753D-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 as an Entry. Or if you go the > Fielding way with the recursive pace, > that a Feed is a structure that is a subclass of the Entry structure. > And then we will really cut the > length of the spec down to its core. Because it's not a summary, which shows that a Feed head isn't quite the same thing as an Entry. It would be conceivable, though perhaps not advisable (I'd have to think about it), to add a subtitle element to entry, but I can't really see adding a summary element to feed. > Henry Story > > On 2 Feb 2005, at 17:17, Julian Reschke wrote: > >> Graham wrote: >>> Any chance of renaming atom:tagline to atom:subtitle? The two sample >>> feeds posted today have the taglines "ongoing fragmented essay by >>> Tim Bray" and "WebDAV related news". Aren't taglines meant to be >>> funny or catchy or clever? >>> The relevant definitions from dictionary.com are: >>> tagline: An often repeated phrase associated with an individual, >>> organization, or commercial product; a slogan. >>> subtitle: A secondary, usually explanatory title, as of a literary >>> work. >>> The second seems much broader and more useful, and there's nothing >>> stopping you using a slogan as subtitle. >> >> +1 > From owner-atom-syntax@mail.imc.org Wed Feb 2 12:33:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02972 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:33:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HE4Cm086303; Wed, 2 Feb 2005 09:14:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HE4wj086302; Wed, 2 Feb 2005 09:14:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HE3Ke086295 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:14:03 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j12HDxkc003701; Wed, 2 Feb 2005 12:13:59 -0500 (EST) Message-ID: <42010A58.6000501@intertwingly.net> Date: Wed, 02 Feb 2005 12:14:00 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story <henry.story@bblfish.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: tagline -> subtitle References: <71234c9ab7c316582d9da9c077b76457@mac.com> <4200FD36.6040004@gmx.de> <bda7fea5bf630212e9dc99fb16e6ffe1@bblfish.net> In-Reply-To: <bda7fea5bf630212e9dc99fb16e6ffe1@bblfish.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 as an Entry. Or if you go the Fielding > way with the recursive pace, > that a Feed is a structure that is a subclass of the Entry structure. > And then we will really cut the > length of the spec down to its core. I'm ambivalent w.r.t. tagline vs subtitle; but changing the name to summary to impose a structure that isn't there doesn't feel right to me. "It's just data" is a tagline. It could conceivably be a subtitle. But it is a summary of what exactly? - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Feb 2 12:42:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04028 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:42:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HCa2P086231; Wed, 2 Feb 2005 09:12:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HCaxM086230; Wed, 2 Feb 2005 09:12:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HCaxU086219 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:12:36 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050202171230016004kmrie>; Wed, 2 Feb 2005 17:12:30 +0000 Date: Wed, 2 Feb 2005 10:12:29 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceIconAndImage - icon aspect ratio From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <9EA76822-753D-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > 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 shouldn't be a MUST? Aren't icons (on computers, anyway) pretty much universally 1:1? From owner-atom-syntax@mail.imc.org Wed Feb 2 12:42:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04077 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:42:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HJLaY086679; Wed, 2 Feb 2005 09:19:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HJLfF086678; Wed, 2 Feb 2005 09:19:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HJL3c086672 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:19:21 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwO9u-0005iv-9x; Wed, 02 Feb 2005 17:19:18 +0000 Message-ID: <42010B94.8020203@franklinmint.fm> Date: Wed, 02 Feb 2005 12:19:16 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy <antone@geckotribe.com> CC: atom-syntax@imc.org Subject: Re: PaceIconAndImage - icon aspect ratio References: <9EA76822-753D-11D9-B0C7-003065EA6144@geckotribe.com> In-Reply-To: <9EA76822-753D-11D9-B0C7-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 why the aspect ratio shouldn't be a MUST? Aren't > icons (on computers, anyway) pretty much universally 1:1? > LiveJournal images are square. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 12:44:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04272 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:44:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HPQ5T087651; Wed, 2 Feb 2005 09:25:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HPQR2087650; Wed, 2 Feb 2005 09:25:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HPPoe087426; Wed, 2 Feb 2005 09:25:25 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id BA7B2122; Wed, 2 Feb 2005 09:25:18 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j12HPDKB004780; Wed, 2 Feb 2005 09:25:18 -0800 (PST) Date: Wed, 02 Feb 2005 09:44:10 -0800 From: Walter Underwood <wunder@verity.com> To: Paul Hoffman <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org> Subject: Re: Format spec vs Protocol spec Message-ID: <BD0FF7049D21114B064CBD02@diva.verity.com> In-Reply-To: <p06200701be2617ba484e@[10.20.30.249]> References: <41FFEF0D.1090200@gmx.de> <p06200701be2617ba484e@[10.20.30.249]> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 chance of that, then Atom 1.0 is a temporary thing, and Atom 1.1 will be the real one. If that is the case, we should leave in the dependency and publish them together. wunder --On Tuesday, February 01, 2005 09:40:38 PM -0800 Paul Hoffman <phoffman@imc.org> wrote: > > At 10:05 PM +0100 2/1/05, Julian Reschke wrote: >> As far as I understand the IETF publication process, this means that >> draft-ietf-atompub-format can't be published until the protocol spec >> is ready as well. > > Others have said we can and should remove the dependency, which is fine. Wearing my nitpicky-IETF-geek hat, I would point out that specs with dangling dependencies can be made standards without clearing the dependencies; they simply can't be published as RFCs with them. There are dozens (possibly over a hundred) IETF standards-track documents that have not yet been published as RFCs for a variety of reasons, many of them quite lame. > > --Paul Hoffman, Director > --Internet Mail Consortium > > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Feb 2 12:46:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04579 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 12:46:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HW5wf088140; Wed, 2 Feb 2005 09:32:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HW5aw088139; Wed, 2 Feb 2005 09:32:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HW59W088131 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:32:05 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 91130 invoked by uid 17064); 2 Feb 2005 17:32:05 -0000 Received: from unknown (HELO [10.20.30.17]) ([195.101.242.1]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 2 Feb 2005 17:32:04 -0000 In-Reply-To: <2309DBF4-753D-11D9-B0C7-003065EA6144@geckotribe.com> References: <2309DBF4-753D-11D9-B0C7-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28677f1b9ba99454fd200a6c67c529b2@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Henry Story <henry.story@bblfish.net> Subject: Re: tagline -> subtitle Date: Wed, 2 Feb 2005 18:32:01 +0100 To: Antone Roundy <antone@geckotribe.com>, Sam Ruby <rubys@intertwingly.net> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 showing that >> a Feed head is the same structure as an Entry. Or if you go the >> Fielding way with the recursive pace, >> that a Feed is a structure that is a subclass of the Entry structure. >> And then we will really cut the >> length of the spec down to its core. > > Because it's not a summary, which shows that a Feed head isn't quite > the same thing as an Entry. You mean you don't see it that way yet ;-) > It would be conceivable, though perhaps not advisable (I'd have to > think about it), to add a subtitle element to entry, but I can't > really see adding a summary element to feed. On 2 Feb 2005, at 18:09, Sam Ruby wrote: > I'm ambivalent w.r.t. tagline vs subtitle; but changing the name to > summary to impose a structure that isn't there doesn't feel right to > me. > > "It's just data" is a tagline. It could conceivably be a subtitle. > But it is a summary of what exactly? Ok. I can agree that a tagline is not a summary. Adding a summary element to a feed does not seem wrong. Consider James Gosling's blog: <http://today.java.net/jag/> The following does not seem out of place as a summary of the feed: ""I've been inescapably tagged as "the Java guy". These days I'm the CTO of Sun's Developer Products group. This now includes the J2SE engineering organization, so I've managed to cycle back. With luck I'll update this blog often enough for it to be interesting."" And if you think that an Entry can be the object of a lot of discussion, and so have responses attached to it, then you can come to see that it would not be so silly to have an Entry have a tagline... Henry Story > >> Henry Story >> >> On 2 Feb 2005, at 17:17, Julian Reschke wrote: >> >>> Graham wrote: >>>> Any chance of renaming atom:tagline to atom:subtitle? The two >>>> sample feeds posted today have the taglines "ongoing fragmented >>>> essay by Tim Bray" and "WebDAV related news". Aren't taglines meant >>>> to be funny or catchy or clever? >>>> The relevant definitions from dictionary.com are: >>>> tagline: An often repeated phrase associated with an individual, >>>> organization, or commercial product; a slogan. >>>> subtitle: A secondary, usually explanatory title, as of a literary >>>> work. >>>> The second seems much broader and more useful, and there's nothing >>>> stopping you using a slogan as subtitle. >>> >>> +1 >> > From owner-atom-syntax@mail.imc.org Wed Feb 2 13:10:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07252 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:10:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HxDms089762; Wed, 2 Feb 2005 09:59:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12HxDJQ089761; Wed, 2 Feb 2005 09:59:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12HxC74089754 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 09:59:12 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so152069rnz for <atom-syntax@imc.org>; Wed, 02 Feb 2005 09:59:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=acqvDXJAmEJ2hEVQRRyGBsS5NDSZWBFvtj/gSdw7lwh2MD9yT3VW5tPVWzqeVTqclb1rxzyG4syjTZbV0Xb15YTxXTHY5y1ppGGRk4kzUp3rZY3/xIndT0KewGnnybh2Udvsdws8UacLV71abIFnQG+6CzPggpdi3LcbTxnMlrY= Received: by 10.38.179.56 with SMTP id b56mr193030rnf; Wed, 02 Feb 2005 09:59:11 -0800 (PST) Received: by 10.38.179.46 with HTTP; Wed, 2 Feb 2005 09:59:11 -0800 (PST) Message-ID: <1f2ed5cd050202095963588da2@mail.gmail.com> Date: Wed, 2 Feb 2005 18:59:11 +0100 From: Danny Ayers <danny.ayers@gmail.com> Reply-To: Danny Ayers <danny.ayers@gmail.com> To: Graham <dtcd@mac.com> Subject: Re: tagline -> subtitle Cc: Atom Syntax <atom-syntax@imc.org> In-Reply-To: <71234c9ab7c316582d9da9c077b76457@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <71234c9ab7c316582d9da9c077b76457@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +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 +0000, Graham <dtcd@mac.com> wrote: > Any chance of renaming atom:tagline to atom:subtitle? The two sample > feeds posted today have the taglines "ongoing fragmented essay by Tim > Bray" and "WebDAV related news". Aren't taglines meant to be funny or > catchy or clever? > > The relevant definitions from dictionary.com are: > tagline: An often repeated phrase associated with an individual, > organization, or commercial product; a slogan. > subtitle: A secondary, usually explanatory title, as of a literary > work. > > The second seems much broader and more useful, and there's nothing > stopping you using a slogan as subtitle. > > Graham > > -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Wed Feb 2 13:24:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09606 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:24:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IC1T6090860; Wed, 2 Feb 2005 10:12:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12IC1jv090859; Wed, 2 Feb 2005 10:12:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IC0xD090846; Wed, 2 Feb 2005 10:12:00 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j12IC0dt005806; Wed, 2 Feb 2005 11:12:00 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA0097UQJZH4@edgemail1.Central.Sun.COM>; Wed, 02 Feb 2005 11:11:59 -0700 (MST) Received: from [10.12.0.13] ([129.150.29.58]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA006JHQJY44@mail.sun.net>; Wed, 02 Feb 2005 11:11:59 -0700 (MST) Date: Wed, 02 Feb 2005 10:12:04 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Format spec vs Protocol spec In-reply-to: <BD0FF7049D21114B064CBD02@diva.verity.com> To: Walter Underwood <wunder@verity.com> Cc: Paul Hoffman <phoffman@imc.org>, Atom Syntax <atom-syntax@imc.org> Message-id: <F15DDC6F-7545-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <41FFEF0D.1090200@gmx.de> <p06200701be2617ba484e@[10.20.30.249]> <BD0FF7049D21114B064CBD02@diva.verity.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 9:44 AM, Walter Underwood wrote: > On the other hand, the original plan was to publish both specs at > the same time, which I still think is a good idea. I don't. I think that if the format depends on the protocol, that's a *bug*, because I'm quite sure that a nice minimal clean general-purpose vocabulary like Atom will find a wide range of applications in areas that we haven't begun to think of, that couldn't care less about publishing protocols. So it would be actively harmful if the format had a dependency on the protocol. The reverse is not true, it's OK for the protocol to depend on the format. Finally, I think the group needs to get the format signed, sealed and delivered so that we can focus our energies on getting the protocol right. -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 13:43:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12434 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:43:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12ITS4l092855; Wed, 2 Feb 2005 10:29:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12ITSWj092854; Wed, 2 Feb 2005 10:29:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12ITRsH092848 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:29:27 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwPFk-0006WK-Nw for atom-syntax@imc.org; Wed, 02 Feb 2005 18:29:24 +0000 Message-ID: <42011C03.5070309@franklinmint.fm> Date: Wed, 02 Feb 2005 13:29:23 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: PaceRemoveInfoAndHost Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit 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 its detractors still oppose it. Design by committee at its worst. Remove atom:info ------------------- Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, it’s easier to shut down a solo raving loony." In the threads on atom:info, it seems I am playing the role of solo raving loony. So, let's have the process take over. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 13:47:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12974 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:47:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IaEqe093440; Wed, 2 Feb 2005 10:36:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12IaEDN093439; Wed, 2 Feb 2005 10:36:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IaDYd093428 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:36:13 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id DC569116 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:36:08 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j12Ia8KB005188 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:36:08 -0800 (PST) Date: Wed, 02 Feb 2005 10:55:06 -0800 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: tagline -> subtitle Message-ID: <DCF8D472A8CE7F8CBF63F53F@diva.verity.com> In-Reply-To: <1f2ed5cd050202095963588da2@mail.gmail.com> References: <71234c9ab7c316582d9da9c077b76457@mac.com> <1f2ed5cd050202095963588da2@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Or "description" instead of "tagline". "subtitle" sounds like a formatting directive to me, "print this smaller and below the title." This is one case where "description" and "summary" are not really the same thing. But it might be confusing, because HTML uses a description meta tag for the summary. Ick. How about "blurb"? American Heritage dictionary has: "A brief publicity notice, as on a book jacket." wunder --On Wednesday, February 02, 2005 06:59:11 PM +0100 Danny Ayers <danny.ayers@gmail.com> wrote: > > +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 +0000, Graham <dtcd@mac.com> wrote: >> Any chance of renaming atom:tagline to atom:subtitle? The two sample >> feeds posted today have the taglines "ongoing fragmented essay by Tim >> Bray" and "WebDAV related news". Aren't taglines meant to be funny or >> catchy or clever? >> >> The relevant definitions from dictionary.com are: >> tagline: An often repeated phrase associated with an individual, >> organization, or commercial product; a slogan. >> subtitle: A secondary, usually explanatory title, as of a literary >> work. >> >> The second seems much broader and more useful, and there's nothing >> stopping you using a slogan as subtitle. >> >> Graham >> >> > > > -- > > http://dannyayers.com > > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Feb 2 13:47:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12996 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:47:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IbbLX093579; Wed, 2 Feb 2005 10:37:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Ibbqt093578; Wed, 2 Feb 2005 10:37:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IbarY093569 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:37:36 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 95018C5 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:37:31 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j12IbVKB005192 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:37:31 -0800 (PST) Date: Wed, 02 Feb 2005 10:56:29 -0800 From: Walter Underwood <wunder@verity.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: Format spec vs Protocol spec Message-ID: <EB87709FE3B53A36B6C8A760@diva.verity.com> In-Reply-To: <F15DDC6F-7545-11D9-968C-000A95A51C9E@sun.com> References: <41FFEF0D.1090200@gmx.de> <p06200701be2617ba484e@[10.20.30.249]> <BD0FF7049D21114B064CBD02@diva.verity.com> <F15DDC6F-7545-11D9-968C-000A95A51C9E@sun.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On Wednesday, February 02, 2005 10:12:04 AM -0800 Tim Bray <Tim.Bray@Sun.COM> wrote: > On Feb 2, 2005, at 9:44 AM, Walter Underwood wrote: > >> On the other hand, the original plan was to publish both specs at >> the same time, which I still think is a good idea. > > I don't. I think that if the format depends on the protocol, that's a *bug*, > because I'm quite sure that a nice minimal clean general-purpose vocabulary > like Atom will find a wide range of applications in areas that we haven't > begun to think of, that couldn't care less about publishing protocols. So it > would be actively harmful if the format had a dependency on the protocol. 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 aspect, so it wouldn't be a complete surprise to find something missing in Atom. We are assuming that Atom will need extensions for new applications, but it should not need extensions for editing blog entries. Mutual dependencies are normal. HTTP and XML have that for encodings. XML talks about encoding specs from transports and HTTP content-type overrides format encodings in the entity. Some areas that might come up are clocks and dates (date from client or server?), security, and editing-only extensions (not copied to feed). An example of the last on is marking an entry as draft or published. That information would not show up in a regular feed, but would be there in a feed used for archiving. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Feb 2 13:57:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13805 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:57:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Ijnl4094459; Wed, 2 Feb 2005 10:45:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12IjnMe094458; Wed, 2 Feb 2005 10:45:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IjmEB094448 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:45:48 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so171246rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 10:45:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YRTv7tlQ8eUDr7/2Yo89+uB4h7fg6abw2RC6/kfmDhOpbxCuURYO6OkTkSXqIU5+d2Mfut5+2koe2w0Cr5uoq1D0bInBv6P5zEnlPBW9lr7pSNjZkMqJegyFgmN09LWGpuZMX38w0mGUVN9j+97Dx81w0556yLTnrhWnKYBJMQI= Received: by 10.38.74.14 with SMTP id w14mr834rna; Wed, 02 Feb 2005 10:45:43 -0800 (PST) Received: by 10.38.151.18 with HTTP; Wed, 2 Feb 2005 10:45:43 -0800 (PST) Message-ID: <3f1451f505020210451779d6d2@mail.gmail.com> Date: Wed, 2 Feb 2005 13:45:43 -0500 From: Joe Gregorio <joe.gregorio@gmail.com> Reply-To: Joe Gregorio <joe.gregorio@gmail.com> To: Robert Sayre <mint@franklinmint.fm> Subject: Re: PaceRemoveInfoAndHost Cc: Atom-Syntax <atom-syntax@imc.org> In-Reply-To: <42011C03.5070309@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <42011C03.5070309@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 On Wed, 02 Feb 2005 13:29:23 -0500, Robert Sayre <mint@franklinmint.fm> wrote: > > 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 its detractors still oppose it. > Design by committee at its worst. > > Remove atom:info > ------------------- > Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, > it's easier to shut down a solo raving loony." In the threads on > atom:info, it seems I am playing the role of solo raving loony. So, > let's have the process take over. > > Robert Sayre > > -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Feb 2 13:59:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14114 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 13:59:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Ilvfg094573; Wed, 2 Feb 2005 10:47:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Ilv0A094572; Wed, 2 Feb 2005 10:47:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Ilu4T094563 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:47:57 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so249867wri for <atom-syntax@imc.org>; Wed, 02 Feb 2005 10:47:49 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=uoj80Os+G975LZa6WOSaAQhKecY32XU+lEftgROQ9bRNB2vEtEbQLDgt/y07hLTm/iv4IAZjbwNth7ab53mKTHNoFq5POsmKJ5TJWaDnYWIlLeE8P+CtZueD291I4CZ7SkeRlG9JZkVd5Wg3aMAkFX9Lhej+MrVB0jzdlncS454= Received: by 10.54.16.2 with SMTP id 2mr50892wrp; Wed, 02 Feb 2005 10:47:49 -0800 (PST) Received: by 10.54.18.2 with HTTP; Wed, 2 Feb 2005 10:47:49 -0800 (PST) Message-ID: <540e3732050202104772509d20@mail.gmail.com> Date: Wed, 2 Feb 2005 12:47:49 -0600 From: "Roger B." <rogben@gmail.com> Reply-To: "Roger B." <rogben@gmail.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceXhtmlNamespaceDiv posted In-Reply-To: <41FD303A.9000305@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <E70FA870-70EF-11D9-9325-003065EA6144@geckotribe.com> <41FD183A.5010208@intertwingly.net> <948dcbcfad76bdfa80b1ffff9541f673@mac.com> <41FD28E6.8000305@gmx.de> <366F29EE-72F1-11D9-9797-000A95A51C9E@sun.com> <41FD303A.9000305@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > 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. I'm gonna be looping over and xmlChildren array no matter what. Requiring the div could certainly make life easier for those who are going to restrict parsing to Atom 1.0, though. -- Roger Benningfield http://admin.support.journurl.com/ From owner-atom-syntax@mail.imc.org Wed Feb 2 14:03:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14580 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:03:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Iract095233; Wed, 2 Feb 2005 10:53:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Iraqe095232; Wed, 2 Feb 2005 10:53:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IrZP6095215 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:53:35 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050202185330015009n063e>; Wed, 2 Feb 2005 18:53:30 +0000 Date: Wed, 2 Feb 2005 11:53:29 -0700 Subject: Re: Format spec vs Protocol spec Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <EB87709FE3B53A36B6C8A760@diva.verity.com> Message-Id: <BA9577EC-754B-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 publishing protocol to live in a separate namespace from the feed itself. Rather, I think that a clean separation between the two would be desirable. Why require the feed format to be revised if we really just want to alter the publishing protocol? From owner-atom-syntax@mail.imc.org Wed Feb 2 14:05:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14713 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:05:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IuHZo095437; Wed, 2 Feb 2005 10:56:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12IuHx4095436; Wed, 2 Feb 2005 10:56:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes28.telusplanet.net (outbound04.telus.net [199.185.220.223]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12IuErD095413 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 10:56:16 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes28.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050202185605.KONT4572.priv-edtnes28.telusplanet.net@dora9> for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:56:05 -0700 Reply-To: <jeremy@jeremygray.ca> From: "Jeremy Gray" <jeremy@jeremygray.ca> To: "'Atom Syntax'" <atom-syntax@imc.org> Subject: RE: tagline -> subtitle Date: Wed, 2 Feb 2005 10:56:05 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <1f2ed5cd050202095963588da2@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJUmvFMZPBbf1nQL67rWgHig2ClQABf2vw Message-Id: <20050202185605.KONT4572.priv-edtnes28.telusplanet.net@dora9> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > +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 might as well toss out a few +/- 1s as I have time while the spec draws to a close. :) +1 for "subtitle" over "tagline", and to using that to increase any possible consistency between feed and entry. -1 for "summary" being merged with / replaced by either. Jeremy Gray From owner-atom-syntax@mail.imc.org Wed Feb 2 14:11:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15518 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:11:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J1Vnp095912; Wed, 2 Feb 2005 11:01:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12J1VVe095911; Wed, 2 Feb 2005 11:01:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J1Q1H095894 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:01:26 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so176289rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 11:01:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mKFG7YIu6YGR4K4M9xbiVewoli5xAVzwv3mHrFWdxMX3VRXTbKX5oUcVTF8GHZLs70vCbE6E70ust8ZKvFMLNG5A97wZAtZOjKTluKAQFXvFO0e7Z19O+UxPlJepeGlKIZH1ox/WLsXDiKN2Ky2rLnwYzNS3Dnhw1rxpTR1JOiE= Received: by 10.38.71.4 with SMTP id t4mr109338rna; Wed, 02 Feb 2005 11:01:25 -0800 (PST) Received: by 10.38.151.18 with HTTP; Wed, 2 Feb 2005 11:01:25 -0800 (PST) Message-ID: <3f1451f505020211013a119339@mail.gmail.com> Date: Wed, 2 Feb 2005 14:01:25 -0500 From: Joe Gregorio <joe.gregorio@gmail.com> Reply-To: Joe Gregorio <joe.gregorio@gmail.com> To: Henry Story <henry.story@bblfish.net> Subject: Re: PaceExtendingAtom Cc: Tim Bray <tbray@textuality.com>, Atom Syntax <atom-syntax@imc.org> In-Reply-To: <5999a03226f1d4e75597a43834a9843e@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> <5999a03226f1d4e75597a43834a9843e@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wed, 2 Feb 2005 18:06:53 +0100, Henry Story <henry.story@bblfish.net> 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 were defined by > something similar to the RELAX NG description we currently have and an > OWL ontology. This would > be helpful and very useful. PaceExtendingAtom as it currently is stated > is restrictive without > being useful. How is PaceExtendingAtom restrictive? It only spells out a Must Ignore policy and nothing else. Am I missing something? -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Feb 2 14:13:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15677 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:13:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J2sTT096042; Wed, 2 Feb 2005 11:02:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12J2sYx096041; Wed, 2 Feb 2005 11:02:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J2r5l096034 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:02:53 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j12J2nKj005180; Wed, 2 Feb 2005 14:02:50 -0500 (EST) Message-ID: <420123DA.4020100@intertwingly.net> Date: Wed, 02 Feb 2005 14:02:50 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceRemoveInfoAndHost References: <42011C03.5070309@franklinmint.fm> In-Reply-To: <42011C03.5070309@franklinmint.fm> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Robert Sayre wrote: > > 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 its detractors still oppose it. > Design by committee at its worst. My name is Sam, and like atom:host (hi Sam!) With that out of the way, I too am prepared to be labeled as a solo raving loony. > Remove atom:info > ------------------- > Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, > it’s easier to shut down a solo raving loony." In the threads on > atom:info, it seems I am playing the role of solo raving loony. So, > let's have the process take over. > > Robert Sayre - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Feb 2 14:18:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16144 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:18:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J6Vg1096332; Wed, 2 Feb 2005 11:06:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12J6VsX096331; Wed, 2 Feb 2005 11:06:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12J6Uei096323 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:06:30 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so177903rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 11:06:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=JAaGJ7E4rduXxdZ3qLETbW2V/mQUnqyVLzvg99TuWNR2bijg6tmM+FQMIQgyc519AUzVCRF9yEm+x1r68t9AzCrtmIK7mon8aTjhA9t7Y/xGMK2pk1tZGVXAySYGkL3C0r8jeHHbMPGEAKpOUGvrEOGpyjsr52hadlaPO1yGHXc= Received: by 10.38.125.66 with SMTP id x66mr354077rnc; Wed, 02 Feb 2005 11:06:29 -0800 (PST) Received: by 10.38.151.18 with HTTP; Wed, 2 Feb 2005 11:06:29 -0800 (PST) Message-ID: <3f1451f5050202110629022442@mail.gmail.com> Date: Wed, 2 Feb 2005 14:06:29 -0500 From: Joe Gregorio <joe.gregorio@gmail.com> Reply-To: Joe Gregorio <joe.gregorio@gmail.com> To: Julian Reschke <julian.reschke@gmx.de> Subject: Re: Format spec vs Protocol spec Cc: Atom Syntax <atom-syntax@imc.org> In-Reply-To: <41FFEF0D.1090200@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FFEF0D.1090200@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Tue, 01 Feb 2005 22:05:17 +0100, Julian Reschke <julian.reschke@gmx.de> 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. This would essentially de-couple the publication process. +1 -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Wed Feb 2 14:24:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16870 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:24:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JAmf6096653; Wed, 2 Feb 2005 11:10:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JAmxE096652; Wed, 2 Feb 2005 11:10:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JAlPP096645 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:10:47 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j12JAldt022303 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:10:47 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBA008FFT9YHR@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 12:10:47 -0700 (MST) Received: from [10.12.0.13] ([129.150.29.58]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBA007ZZT9YOK@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 12:10:46 -0700 (MST) Date: Wed, 02 Feb 2005 11:10:52 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: PaceRemoveInfoAndHost In-reply-to: <42011C03.5070309@franklinmint.fm> To: Robert Sayre <mint@franklinmint.fm> Cc: Atom-Syntax <atom-syntax@imc.org> Message-id: <2857A3B0-754E-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <42011C03.5070309@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceRemoveInfoAndHost +1 -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 14:25:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16927 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:25:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JBp1M096725; Wed, 2 Feb 2005 11:11:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JBpaF096724; Wed, 2 Feb 2005 11:11:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JBoFj096717 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:11:50 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwPul-00072Y-8g; Wed, 02 Feb 2005 19:11:47 +0000 Message-ID: <420125F2.7080402@franklinmint.fm> Date: Wed, 02 Feb 2005 14:11:46 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood <wunder@verity.com> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: Format spec vs Protocol spec References: <41FFEF0D.1090200@gmx.de> <p06200701be2617ba484e@[10.20.30.249]> <BD0FF7049D21114B064CBD02@diva.verity.com> <F15DDC6F-7545-11D9-968C-000A95A51C9E@sun.com> <EB87709FE3B53A36B6C8A760@diva.verity.com> In-Reply-To: <EB87709FE3B53A36B6C8A760@diva.verity.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 aspect, > so it wouldn't be a complete surprise to find something missing in Atom. > One of the demonstrated problems in syndication[0] and editing APIs is representation of collections with collections. ------------------------------- Disclaimer: The following paragraph is not an edorsement of WebDAV's requirements, syntax, or extension of HTTP. ------------------------------- One thing WebDAV does get right to some extent is representation of sub-collections. This approach is provably effective. Some example applications based on this approach: * Outlook Web Access is based entirely on XSL-transformed DAV XML, and Javascript's XMLHttpRequest. * Outlook Express's Hotmail accounts use this protocol as well. The problems facing a server storing blog entries are not much different (whether or not the entries are exposed to APP). The implementation requirements of those protocols far excede anything we can expect, but some aspects of the model would be extremely valuable to the format and protocol, IMHO. Robert Sayre [0] http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0 From owner-atom-syntax@mail.imc.org Wed Feb 2 14:26:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17060 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:26:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JEWE7096896; Wed, 2 Feb 2005 11:14:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JEWio096895; Wed, 2 Feb 2005 11:14:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JEVef096887 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:14:31 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id E5C7DFB for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:14:26 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j12JEQLf005469 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:14:26 -0800 (PST) Date: Wed, 02 Feb 2005 11:33:23 -0800 From: Walter Underwood <wunder@verity.com> To: atom-syntax@imc.org Subject: Re: Format spec vs Protocol spec Message-ID: <701DD8792C0511A282564607@diva.verity.com> In-Reply-To: <BA9577EC-754B-11D9-B0C7-003065EA6144@geckotribe.com> References: <BA9577EC-754B-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy <antone@geckotribe.com> 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 to disagree. I don't think it inappropriate for elements that exist for use by the publishing protocol to live in a separate namespace from the feed itself. Rather, I think that a clean separation between the two would be desirable. Why require the feed format to be revised if we really just want to alter the publishing protocol? I'm not talking about altering the publishing protcol, I'm talking about things needed to make 1.0 work. It would seem a little odd if we needed extensions or a 1.1 for the 1.0 publishing protocol. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Wed Feb 2 14:48:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19676 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:48:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JZbaf098759; Wed, 2 Feb 2005 11:35:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JZbi2098758; Wed, 2 Feb 2005 11:35:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JZbaY098745 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:35:37 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020219353101100chrl8e>; Wed, 2 Feb 2005 19:35:31 +0000 Date: Wed, 2 Feb 2005 12:35:31 -0700 Subject: Re: Format spec vs Protocol spec Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <701DD8792C0511A282564607@diva.verity.com> Message-Id: <996FC23E-7551-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wednesday, February 2, 2005, at 12:33 PM, Walter Underwood wrote: > --On Wednesday, February 02, 2005 11:53:29 AM -0700 Antone Roundy > <antone@geckotribe.com> 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 to disagree. I don't think it inappropriate for elements >> that exist for use by the publishing protocol to live in a separate >> namespace from the feed itself. Rather, I think that a clean >> separation between the two would be desirable. Why require the feed >> format to be revised if we really just want to alter the publishing >> protocol? > > I'm not talking about altering the publishing protcol, Right, I was just saying that if, someday, after format 1.0 and protocol 1.0 are out, we discover the need to alter the protocol, have the two separated from either other would enable us to do that without affecting applications that use the format but not the protocol. > I'm talking about things > needed to make 1.0 work. It would seem a little odd if we needed > extensions > or a 1.1 for the 1.0 publishing protocol. Let me make sure I understand you correctly--are you saying that it's fine for the format and protocol to have their own elements in their own namespaces, but 1.0 of each should be finished at the same time, to ensure that we don't run into any surprises while finishing protocol 1.0 which require a format revision (eg. 1.1) in order to make protocol 1.0 work? Or are you saying that everything needed for editing should be in the format namespace, not an extension? I suppose I can't comment on the former, because I haven't been involved in the protocol discussion, but I definitely wouldn't agree with the latter. From owner-atom-syntax@mail.imc.org Wed Feb 2 14:56:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21024 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 14:56:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Jf4gh099131; Wed, 2 Feb 2005 11:41:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Jf4Ek099130; Wed, 2 Feb 2005 11:41:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JexlV099117 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:40:59 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 29859 invoked by uid 17064); 2 Feb 2005 19:40:59 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.0.44]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <atom-syntax@imc.org>; 2 Feb 2005 19:40:59 -0000 In-Reply-To: <3f1451f505020211013a119339@mail.gmail.com> References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> <5999a03226f1d4e75597a43834a9843e@bblfish.net> <3f1451f505020211013a119339@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9399fcba8d406171d474d565ad8943a3@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org>, Tim Bray <tbray@textuality.com> From: Henry Story <henry.story@bblfish.net> Subject: Re: PaceExtendingAtom Date: Wed, 2 Feb 2005 20:40:33 +0100 To: Joe Gregorio <joe.gregorio@gmail.com> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit [[ 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 PaceExtendingAtom restrictive? It only spells out a Must Ignore > policy and nothing else. Am I missing something? > > -joe > From owner-atom-syntax@mail.imc.org Wed Feb 2 15:11:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23044 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 15:11:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JwCnN000522; Wed, 2 Feb 2005 11:58:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12JwC6S000521; Wed, 2 Feb 2005 11:58:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12JwBYJ000513 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 11:58:11 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so195336rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 11:58:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=J3C6BA7RBeho9Q5JJQ7fo9a9YzFEiuYCuJdVhtT27EkPUf+PNZmVcpwD14WlJzZyDP7Uz1WhGJupjs6LvFwbx2iTE3zLUp4rN8n2w1LrondwVKMBycTGCEdI0zLqpBlp6Ncllxf4bucQgf8t/WwyL9i/PcskL8Dmc3bAgUtrPV8= Received: by 10.38.102.18 with SMTP id z18mr158710rnb; Wed, 02 Feb 2005 11:58:07 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 11:58:07 -0800 (PST) Message-ID: <2bcdc7c40502021158637bb7ed@mail.gmail.com> Date: Wed, 2 Feb 2005 11:58:07 -0800 From: James Snell <jasnell@gmail.com> Reply-To: James Snell <jasnell@gmail.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Thinking ahead: Atom Extension Proposals on the Wiki? In-Reply-To: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 finalized? What I imagine is a system similar to Pace proposals except using a naming prefix such as Ext instead. E.g. ExtLinkContentDigest or ExtFeedEntryLicense etc. Discussion about the proposals would be limited to the wiki or "private" email conversations (e.g. kept off the ietf mailing list unless, for whatever reason, it is deemed appropriate for list discussion by the WG chairs). Thoughts? -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed Feb 2 15:18:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23856 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 15:18:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12K74sR001340; Wed, 2 Feb 2005 12:07:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12K74RQ001339; Wed, 2 Feb 2005 12:07:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12K74M2001331 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:07:04 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 34D5E123 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:06:59 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j12K6vLf005831 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:06:58 -0800 (PST) Date: Wed, 02 Feb 2005 12:06:58 -0800 From: Walter Underwood <wunder@verity.com> To: atom-syntax@imc.org Subject: Re: Format spec vs Protocol spec Message-ID: <AB27870B82DE40A0C0D09931@Wunders-Computer.local> In-Reply-To: <996FC23E-7551-11D9-B0C7-003065EA6144@geckotribe.com> References: <996FC23E-7551-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Correct. --wunder --On February 2, 2005 12:35:31 PM -0700 Antone Roundy <antone@geckotribe.com> wrote: > Let me make sure I understand you correctly--are you saying that it's fine for the format and protocol to have their own elements in their own namespaces, but 1.0 of each should be finished at the same time, to ensure that we don't run into any surprises while finishing protocol 1.0 which require a format revision (eg. 1.1) in order to make protocol 1.0 work? -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Wed Feb 2 15:27:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25109 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 15:27:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KFNQi002214; Wed, 2 Feb 2005 12:15:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KFNG4002213; Wed, 2 Feb 2005 12:15:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KFM28002206 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:15:22 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwQuC-0007cg-8I; Wed, 02 Feb 2005 20:15:16 +0000 Message-ID: <420134D3.2090400@franklinmint.fm> Date: Wed, 02 Feb 2005 15:15:15 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: Walter Underwood <wunder@verity.com>, Atom Syntax <atom-syntax@imc.org> Subject: Organization Use Cases (was: Re: Format spec vs Protocol spec) References: <41FFEF0D.1090200@gmx.de> <p06200701be2617ba484e@[10.20.30.249]> <BD0FF7049D21114B064CBD02@diva.verity.com> <F15DDC6F-7545-11D9-968C-000A95A51C9E@sun.com> <EB87709FE3B53A36B6C8A760@diva.verity.com> <420125F2.7080402@franklinmint.fm> In-Reply-To: <420125F2.7080402@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > The problems facing a server storing blog entries are not much different > (whether or not the entries are exposed to APP). Our secretary has listed the following paces as "organization" paces, meaning they don't change the definition of many core elements other than the ones serving as "containers". * PaceAggregationDocument * PaceFeedRecursive 1.) A web forum, where one post serves as the root of a collection of other posts. HTML-- http://groups-beta.google.com/group/bloggerDev/ Atom 0.3, "root" posts only-- http://groups-beta.google.com/group/bloggerDev/feed/topics.xml Atom 0.3, all messages-- http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml 2.) A Blog w/ comments, where on post serves as the root of a collection of other posts. HTML-- http://www.livejournal.com/users/giant_moose/ Atom 0.3, no indication of comments-- http://www.livejournal.com/users/giant_moose/data/atom 3.) A "List Status" feed, where the only updates consist of one collection replacing another. RSS2 -- http://rss.netflix.com/Top100RSS background info-- http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd-4cba-959a-2bba6ae917f0 Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 15:34:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25905 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 15:34:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KAEub001527; Wed, 2 Feb 2005 12:10:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12KAEUu001526; Wed, 2 Feb 2005 12:10:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KADwC001508 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 12:10:13 -0800 (PST) (envelope-from lavandowska@gmail.com) Received: by wproxy.gmail.com with SMTP id 40so190706wri for <atom-syntax@imc.org>; Wed, 02 Feb 2005 12:10:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=l9k4YDrEvrbtC9FciqHPPARIGgfz9vS/USQ9co74obSh0QZJrvUYo5VqaxCB3FWkpenz5RIzqlds3HWZkTg/FKiVucNG0H34yGHh9dZO7S3tPO+X5g1PeJ80DcyQj+WH1IdfRUAcVB76RHOja5eIiSwDHJ3u0MiuJHhAsmIi50w= Received: by 10.54.17.37 with SMTP id 37mr356371wrq; Wed, 02 Feb 2005 12:10:07 -0800 (PST) Received: by 10.54.59.13 with HTTP; Wed, 2 Feb 2005 12:10:07 -0800 (PST) Message-ID: <96d7d77c0502021210c66a511@mail.gmail.com> Date: Wed, 2 Feb 2005 14:10:07 -0600 From: Lance Lavandowska <lavandowska@gmail.com> Reply-To: Lance Lavandowska <lavandowska@gmail.com> To: Atom Syntax <atom-syntax@imc.org> Subject: Re: tagline -> subtitle In-Reply-To: <DCF8D472A8CE7F8CBF63F53F@diva.verity.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <71234c9ab7c316582d9da9c077b76457@mac.com> <1f2ed5cd050202095963588da2@mail.gmail.com> <DCF8D472A8CE7F8CBF63F53F@diva.verity.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wed, 02 Feb 2005 10:55:06 -0800, Walter Underwood <wunder@verity.com> 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 really > the same thing. But it might be confusing, because HTML uses a > description meta tag for the summary. Ick. The difference between "summary" and "description/subtitle" is that the former is a shorter version of something else, whereas the latter is an expanded version. > How about "blurb"? American Heritage dictionary has: "A brief publicity > notice, as on a book jacket." I would prefer "blurb" over "description". I like "subtitle" better than either. Lance From owner-atom-syntax@mail.imc.org Wed Feb 2 18:37:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA26978 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 18:37:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NM8Xt015168; Wed, 2 Feb 2005 15:22:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12NM8l6015167; Wed, 2 Feb 2005 15:22:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NM7me015157 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 15:22:07 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so256196rne for <atom-syntax@imc.org>; Wed, 02 Feb 2005 15:22:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CkkL7VTXOXbjX8wMOQb6NjN3jMvW5x1ncOi+x/Xy1bS0jcsC2POdk5KoH7J+CiWqugdhgOrpXMRPyM0iW73v1xDeSpPo46W/zbNL3UBNnNvS/S33ZBBOEFvxb6JZbfcqpLrCfT/TTYspa19oQkgF//wm6Vq4KlPDpZJkMM/i6yI= Received: by 10.38.74.14 with SMTP id w14mr163398rna; Wed, 02 Feb 2005 15:21:18 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 15:21:18 -0800 (PST) Message-ID: <2bcdc7c405020215216b192094@mail.gmail.com> Date: Wed, 2 Feb 2005 15:21:18 -0800 From: James Snell <jasnell@gmail.com> Reply-To: James Snell <jasnell@gmail.com> To: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Thinking ahead: Atom Extension Proposals on the Wiki? Cc: Atom Syntax <atom-syntax@imc.org> In-Reply-To: <C9F5F887-7570-11D9-968C-000A95A51C9E@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> <2bcdc7c40502021158637bb7ed@mail.gmail.com> <C9F5F887-7570-11D9-968C-000A95A51C9E@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Wed, 02 Feb 2005 15:18:46 -0800, Tim Bray <Tim.Bray@sun.com> 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 Wiki as the forum for sharing proposals > > for extensions once the core syntax has been finalized? > > Sounds like a good idea to me. Mind you, it's Sam's wiki :) -Tim > > Heh, good point ;-) ... Sam? Ultimately it is your call. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Wed Feb 2 18:38:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27075 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 18:38:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NIeiW015006; Wed, 2 Feb 2005 15:18:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12NIejo015005; Wed, 2 Feb 2005 15:18:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NIdmD014999 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 15:18:39 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j12NIdVu004044 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 16:18:39 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBB009QQ4R2A9@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Wed, 02 Feb 2005 16:18:39 -0700 (MST) Received: from [129.145.225.211] by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBB0069B4R244@mail.sun.net> for atom-syntax@imc.org; Wed, 02 Feb 2005 16:18:38 -0700 (MST) Date: Wed, 02 Feb 2005 15:18:46 -0800 From: Tim Bray <Tim.Bray@Sun.COM> Subject: Re: Thinking ahead: Atom Extension Proposals on the Wiki? In-reply-to: <2bcdc7c40502021158637bb7ed@mail.gmail.com> To: James Snell <jasnell@gmail.com> Cc: Atom Syntax <atom-syntax@imc.org> Message-id: <C9F5F887-7570-11D9-968C-000A95A51C9E@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> <2bcdc7c40502021158637bb7ed@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7BIT 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 finalized? Sounds like a good idea to me. Mind you, it's Sam's wiki :) -Tim From owner-atom-syntax@mail.imc.org Wed Feb 2 19:03:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29262 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 19:03:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NpSgh017069; Wed, 2 Feb 2005 15:51:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12NpSis017068; Wed, 2 Feb 2005 15:51:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12NpQm9017037 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 15:51:27 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050202235119.GTWZ8887.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com> for <atom-syntax@imc.org>; Wed, 2 Feb 2005 23:51:19 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050202235119.EMGL1438.aamta06-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for <atom-syntax@imc.org>; Wed, 2 Feb 2005 23:51:19 +0000 Date: Wed, 2 Feb 2005 23:51:17 +0000 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <13710384749.20050202235117@djpowell.net> To: Atom Syntax <atom-syntax@imc.org> Subject: RELAX-NG bug in draft-05? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 From owner-atom-syntax@mail.imc.org Wed Feb 2 19:25:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01157 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 19:25:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j130Da8J018059; Wed, 2 Feb 2005 16:13:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j130Da72018058; Wed, 2 Feb 2005 16:13:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j130Dajc018050 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 16:13:36 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwUcl-000153-K6 for atom-syntax@imc.org; Thu, 03 Feb 2005 00:13:31 +0000 Message-ID: <42016CAA.2000000@franklinmint.fm> Date: Wed, 02 Feb 2005 19:13:30 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: PaceEntriesElement Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceEntriesElement Abstract ------------------------- Remove atom:head, group entries with atom:entries instead. Allow feeds to contain atom:summary and atom:content (Folders are Resources Too!). Use cases: http://www.imc.org/atom-syntax/mail-archive/msg12963.html Status ------------------------- Open Rationale ------------------------- Making a feed document strictly hierarchical and recursive solves a number of problems that have been previously attacked in a piecemeal fashion: 1. XML containment relates feed and entry metadata to the data being described, thereby defining a consistent model for future extension elements; 2. Multiple feeds can be aggregated and presented using a single data format without having to modify the entries within those feeds to incorporate their original feed metadata; 3. Digital signatures can be safely applied to feeds and entries without needing special-case exceptions on how to recreate the signature after aggregation; 4. Simplifies description of the Atom syndication format to containers (feed, entries, entry, content) and metadata that targets its own parent (feed or entry). 5. Allows Hierarchical feeds, comments. 6. Practically zero changes for format05 feeds in the simple case. Entry elements are wrapped with atom:entries instead of headers being wrapped with atom:head. 7. Differentiates elements lower in a hierarchy (collection members) from metadata. From owner-atom-syntax@mail.imc.org Wed Feb 2 19:50:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03240 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 19:50:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j130cRvn019875; Wed, 2 Feb 2005 16:38:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j130cRLM019874; Wed, 2 Feb 2005 16:38:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j130cQ9k019865 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 16:38:26 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta08-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050203003821.MSKR8887.mta08-winn.mailhost.ntl.com@aamta08-winn.mailhost.ntl.com> for <atom-syntax@imc.org>; Thu, 3 Feb 2005 00:38:21 +0000 Received: from cpc1-stke1-5-0-cust43.bagu.cable.ntl.com ([81.97.134.43]) by aamta08-winn.mailhost.ntl.com with ESMTP id <20050203003821.MHNF26737.aamta08-winn.mailhost.ntl.com@cpc1-stke1-5-0-cust43.bagu.cable.ntl.com> for <atom-syntax@imc.org>; Thu, 3 Feb 2005 00:38:21 +0000 Date: Thu, 3 Feb 2005 00:18:38 +0000 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1311114903.20050203001838@djpowell.net> CC: Atom Syntax <atom-syntax@imc.org> Subject: Posted PaceEntryOrder (was Entry order) In-Reply-To: <158887418.20050201230634@djpowell.net> References: <158887418.20050201230634@djpowell.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I think we need to decide one way or the other whether the order of atom:entry elements is significant, so I've just posted PaceEntryOrder: http://www.intertwingly.net/wiki/pie/PaceEntryOrder == Abstract == Specify that the order of atom:entry elements within an Atom Feed Document is not significant. == Status == Open Author: DavidPowell == Rationale == Atom 0.3 stated that: {{{ Ordering of the element children of atom:feed element MUST NOT be considered significant. }}} This text seems to have got lost somewhere during the introduction of atom:head. Currently the specification doesn't say whether entries are ordered or not, which is likely to lead to confusion. If the specification is not clear about whether processors are supposed to preserve the order of entries or not, then some database-based implementations might preserve the order and others might not. == Proposal == Add the following sentence to Section 4.1 : {{{ This specification assigns no significance to the order of atom:entry elements within the feed. Processors MAY present entries in a different order to which they are appear in an Atom Feed Document. }}} -- Dave From owner-atom-syntax@mail.imc.org Wed Feb 2 20:30:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06272 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 20:30:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131J6K1022077; Wed, 2 Feb 2005 17:19:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j131J62f022076; Wed, 2 Feb 2005 17:19:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131J6gx022068 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 17:19:06 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050203011858015009klmfe>; Thu, 3 Feb 2005 01:18:58 +0000 Date: Wed, 2 Feb 2005 18:18:58 -0700 Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <9831AF60-748C-11D9-9FA4-003065EA6144@geckotribe.com> Message-Id: <94A7D0FC-7581-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 that don't hand of HTML content to some widget for > handling, and thus have to handle the details of loading images and > such themselves, but for applications that do, it's much simpler to be > able to get everything that they need to manipulate with one request > and be done with it. We already have indirection for <content>, which > I personally would be happier without. I'd like to avoid adding more. > Having looked at PaceEntriesElement, my perspective on this has changed slightly--indirection at atom:feed would be good, but by using link, not recursive feeds. The blog post and comments use case is indeed one that isn't addressed by the current draft. I think that building the ability to stuff a whole hierarchical forum into a recursive feed into the core format would add an unnecessary burden of complexity for people who just want flat feeds like what we've been working with to this point. Linking to a feed of comments from an entry (whether a blog or forum post) would be a simple way to enable such hierarchical organization without making the format more complex. So, rather than this: <feed> <id>1</id> <entries> <feed> <id>2</id> <content /> <entries> <entry /> <entry /> </entries> </feed> <entry /> <entry /> </entries> </feed> You could do this: <feed> <id>1</id> <entry> <content /> <link rel="comments" type="application/atom+xml" ... /> </entry> <entry /> <entry /> </feed> and: <feed> <id>2</td> <entry /> <entry /> </feed> That's been suggested before, but for some reason hasn't been pursued vigorously enough to get into the current draft. What's missing is that the content of the entry that's at the top of the second feed is missing from the feed. According to my mental model of a feed, the correct thing to do would be to put something like <link rel="about" href="URL of entry" /> into feed 2's head. But that would be too inconvenient, so I'd rather allow atom:content and atom:summary in atom:feed for these cases. And lest anyone say "See! A feed is an entry!", I still don't see it that way. Instead, I see this as a convenient way to spawn a feed related to an entry when appropriate, and a feed has been given some of the attributes of an entry for convenience. From owner-atom-syntax@mail.imc.org Wed Feb 2 20:37:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06839 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 20:37:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131RWin023030; Wed, 2 Feb 2005 17:27:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j131RWbK023029; Wed, 2 Feb 2005 17:27:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131RVUC023023 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 17:27:32 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j131RRKj003866; Wed, 2 Feb 2005 20:27:28 -0500 (EST) Message-ID: <42017E00.5000900@intertwingly.net> Date: Wed, 02 Feb 2005 20:27:28 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snell <jasnell@gmail.com> CC: Tim Bray <Tim.Bray@Sun.COM>, Atom Syntax <atom-syntax@imc.org> Subject: Re: Thinking ahead: Atom Extension Proposals on the Wiki? References: <D0B5CECA-6590-11D9-9616-000A95A51C9E@textuality.com> <2bcdc7c40502021158637bb7ed@mail.gmail.com> <C9F5F887-7570-11D9-968C-000A95A51C9E@sun.com> <2bcdc7c405020215216b192094@mail.gmail.com> In-Reply-To: <2bcdc7c405020215216b192094@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit James Snell wrote: > On Wed, 02 Feb 2005 15:18:46 -0800, Tim Bray <Tim.Bray@sun.com> 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 Wiki as the forum for sharing proposals >>>for extensions once the core syntax has been finalized? >> >>Sounds like a good idea to me. Mind you, it's Sam's wiki :) -Tim > > Heh, good point ;-) ... Sam? Ultimately it is your call. Go4it. - Sam Ruby From owner-atom-syntax@mail.imc.org Wed Feb 2 21:02:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08852 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 21:02:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131p15d024250; Wed, 2 Feb 2005 17:51:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j131p13b024249; Wed, 2 Feb 2005 17:51:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j131oxGc024240 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 17:51:00 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06200717be272f60a496@[10.20.30.249]> Date: Wed, 2 Feb 2005 17:46:51 -0800 To: Atom WG <atom-syntax@imc.org> From: Paul Hoffman <phoffman@imc.org> Subject: Call for final Paces for consideration: deadline imminent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> 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, and a couple of promises that "I'll write that up as a Pace soon". We need to finish soon in order to make our milestone, and I believe we can do so gracefully. On Monday, Feb. 7, the Working Group's final queue rotation will consist of all Paces open at that time. Any Paces that have obvious holes in them ("to be filled in later", "more needs to go here", etc.) will be ignored. We have had over a year of time here, and many weeks since the previous attempt to close things out. On Monday, Feb. 14, we will assess WG consensus and ask the document authors to put together a final draft. Note that this is not the last opportunity for work on the Atom format. For one thing, there are plenty of non-core extensions that folks have been mulling over; having the core draft finally finished will help those to emerge. Further, we need to do the final work on the protocol document. Also, during the formal IETF Last Call, discussion of the format draft will be welcome from everyone (including people who have not read any of the earlier drafts). 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. If your idea is appropriate as an extension, or is for something that is quite similar to something else that has explicitly gotten lack of consensus, please do not write a Pace. In the former case, please hold your extensions for a few weeks; in the latter case, please recognize that asking the WG to focus on something that they don't want will likely cause us to do a worse job at carefully reviewing things that we all want. So, if you have an incomplete Pace now, you have a few more days to complete it. Of course, everyone should feel free to continue talking about the current Paces now, and to continue to suggest editorial changes to the current Internet Draft. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Feb 2 21:26:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11623 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 21:26:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132GaBJ025694; Wed, 2 Feb 2005 18:16:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j132GaHK025693; Wed, 2 Feb 2005 18:16:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes46.telusplanet.net (defout.telus.net [199.185.220.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132GZSL025684 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 18:16:35 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050203021630.VUHV18486.priv-edtnes46.telusplanet.net@dora9> for <atom-syntax@imc.org>; Wed, 2 Feb 2005 19:16:30 -0700 Reply-To: <jeremy@jeremygray.ca> From: "Jeremy Gray" <jeremy@jeremygray.ca> To: <atom-syntax@imc.org> Subject: RE: Principled Reasoning. was: PaceAggregationDocument posted Date: Wed, 2 Feb 2005 18:16:28 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <94A7D0FC-7581-11D9-B0C7-003065EA6144@geckotribe.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJj9umAOP2/nJ5SoiQrGZZLywlIQABe0rQ Message-Id: <20050203021630.VUHV18486.priv-edtnes46.telusplanet.net@dora9> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Antone Roundy > Sent: Wednesday, February 02, 2005 5:19 PM > To: atom-syntax@imc.org > Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted --snip-- > And lest anyone say "See! A feed is an entry!" I'll do it. See! A feed is an entry. Not exactly as you've specified it, nor exactly as David has, either, but it is very much true, captures things that have not yet been captured in the spec, and still has the potential to simplify the spec at the same time. All that's needed now are a few open minds. I hope to respond in more detail on this later, but I've only taken one reading pass through David's Pace so far and my time for the evening is being rapidly sapped. :( Jeremy Gray From owner-atom-syntax@mail.imc.org Wed Feb 2 22:08:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15245 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 22:08:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132vIZH027747; Wed, 2 Feb 2005 18:57:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j132vHP6027746; Wed, 2 Feb 2005 18:57:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132vHAa027732; Wed, 2 Feb 2005 18:57:17 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwXB7-0002kx-5o; Thu, 03 Feb 2005 02:57:09 +0000 Message-ID: <42019301.20506@franklinmint.fm> Date: Wed, 02 Feb 2005 21:57:05 -0500 From: Robert Sayre <mint@franklinmint.fm> Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman <phoffman@imc.org> CC: Atom WG <atom-syntax@imc.org> Subject: Re: Call for final Paces for consideration: deadline imminent References: <p06200717be272f60a496@[10.20.30.249]> In-Reply-To: <p06200717be272f60a496@[10.20.30.249]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 out a critical bug or missing feature in the format, and a significant number of WG participants agree, we should miss our deadline because we no longer have consensus on the *current draft*. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 22:08:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15265 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 22:08:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132sZlm027576; Wed, 2 Feb 2005 18:54:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j132sZoX027574; Wed, 2 Feb 2005 18:54:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes46.telusplanet.net (defout.telus.net [199.185.220.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j132sYi2027555 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 18:54:34 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050203025429.YBMF18486.priv-edtnes46.telusplanet.net@dora9> for <atom-syntax@imc.org>; Wed, 2 Feb 2005 19:54:29 -0700 Reply-To: <jeremy@jeremygray.ca> From: "Jeremy Gray" <jeremy@jeremygray.ca> To: <atom-syntax@imc.org> Subject: RE: Principled Reasoning. was: PaceAggregationDocument posted Date: Wed, 2 Feb 2005 18:54:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050203021630.VUHV18486.priv-edtnes46.telusplanet.net@dora9> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJj9umAOP2/nJ5SoiQrGZZLywlIQABe0rQAAFlcFA= Message-Id: <20050203025429.YBMF18486.priv-edtnes46.telusplanet.net@dora9> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jeremy Gray Sent: Wednesday, February 02, 2005 6:16 PM To: atom-syntax@imc.org Subject: RE: Principled Reasoning. was: PaceAggregationDocument posted > -----Original Message----- > From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Antone Roundy > Sent: Wednesday, February 02, 2005 5:19 PM > To: atom-syntax@imc.org > Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted --snip-- > And lest anyone say "See! A feed is an entry!" I'll do it. See! A feed is an entry. Not exactly as you've specified it, nor exactly as David has, either, but it is very much true, captures things that have not yet been captured in the spec, and still has the potential to simplify the spec at the same time. All that's needed now are a few open minds. I hope to respond in more detail on this later, but I've only taken one reading pass through David's Pace so far and my time for the evening is being rapidly sapped. :( Jeremy Gray From owner-atom-syntax@mail.imc.org Wed Feb 2 22:11:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15458 for <atompub-archive@lists.ietf.org>; Wed, 2 Feb 2005 22:11:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1331S1E027965; Wed, 2 Feb 2005 19:01:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1331SAC027964; Wed, 2 Feb 2005 19:01:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes46.telusplanet.net (defout.telus.net [199.185.220.240]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1331RMs027953 for <atom-syntax@imc.org>; Wed, 2 Feb 2005 19:01:28 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes46.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050203030122.YMZQ18486.priv-edtnes46.telusplanet.net@dora9>; Wed, 2 Feb 2005 20:01:22 -0700 Reply-To: <jeremy@jeremygray.ca> From: "Jeremy Gray" <jeremy@jeremygray.ca> To: "'Robert Sayre'" <mint@franklinmint.fm>, "'Atom-Syntax'" <atom-syntax@imc.org> Subject: RE: PaceEntriesElement Date: Wed, 2 Feb 2005 19:01:22 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42016CAA.2000000@franklinmint.fm> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJhsVHMDLIEcrUSsKJ0QHeT3cYiAAFOzfQ Message-Id: <20050203030122.YMZQ18486.priv-edtnes46.telusplanet.net@dora9> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit 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 similar paces have been presented over time, and I must admit that I have not had the time I would like in order to review each in turn, so for the moment I'm going to make a few specific comments on PaceEntryOrder and will then try to find a bit of time this evening to re-review the other proposals before commenting in much more detail. The pace page on the wiki has a few things on which I'd like to comment, some could be typo-type errors, some could be conceptual bits I either don't understand or perhaps just don't agree with :). We'll see. On with the list: - The pace mentions atom:head in its 4.1.2 text, but my impression of the pace is that it would deprecate atom:head. - The pace, in its text for 4.1.2, mentions how a feed can have any number of entry elements. From the example, however, my impression of the pace would be that the feed must have one entries element, which can then in turn have any number of entry elements. I'll state my preference further in this email, but would appreciate some clarification on what is being proposed by the pace. - The pace, in its text for 4.1.2, states atom:contributor cardinality rules in the "MUST NOT" style text that conflict with the schema-style text There may be others worth noting, but I'm out of time for my initial review pass and must head out of the office. I'll try to do another scan, including a review of the other similar paces, later tonight if I have a bit of time. In the meantime, a few more "out there" pieces of food for thought in descending order of priority from my perspective: - merge <entry> and <feed> into <item>, then merge child elements - add a linking construct that can support "item detail by reference", ala the following pseudo-markup example: <item> <items> <item> <title>... ... ... ... ... ... Whether via or not, something like this would be very useful and powerful indeed. May, as-is or with further refinement, handle Antone's indirection desires. - remove , hang children directly from the parent. If not, at least rename it to match whatever "item"-related renaming might take place - simmer - enjoy I'll see what I can do about setting aside some time to more clearly document my thoughts, but figured it would at least be worthwhile providing the above comments and food for thought. Since I've really scrambled to type up this email and get out of the office, I've likely written some confusing or outright erroneous text. If anyone has any questions or comments, don't hesitate to contact me on-list or off. Even if I don't end up finding time to help with the production of actual pace text, I'm more than happy to discuss the involved issues. Jeremy Gray From owner-atom-syntax@mail.imc.org Wed Feb 2 22:24:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16866 for ; Wed, 2 Feb 2005 22:24:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133D8vn029032; Wed, 2 Feb 2005 19:13:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j133D8gU029031; Wed, 2 Feb 2005 19:13:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133D7x8029014 for ; Wed, 2 Feb 2005 19:13:07 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020303125101200g9o33e>; Thu, 3 Feb 2005 03:12:52 +0000 Date: Wed, 2 Feb 2005 20:12:51 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceAggregationDocument updated From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <7D4067EF-7591-11D9-B0C7-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 to being direct descendants of atom:feed (and atom:aggregation). I believe we created atom:head to make it easier to mandate the feed metadata coming before all entries in a feed, so proposals that replace the purpose of PaceHeadInEntry doesn't necessarily suggest doing away with atom:head. From owner-atom-syntax@mail.imc.org Wed Feb 2 22:41:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA18246 for ; Wed, 2 Feb 2005 22:41:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133SiQu030643; Wed, 2 Feb 2005 19:28:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j133Si8v030642; Wed, 2 Feb 2005 19:28:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133Sghb030618; Wed, 2 Feb 2005 19:28:42 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42019301.20506@franklinmint.fm> References: <42019301.20506@franklinmint.fm> Date: Wed, 2 Feb 2005 19:28:14 -0800 To: mint@franklinmint.fm From: Paul Hoffman Subject: Re: Call for final Paces for consideration: deadline imminent Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 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 condition. If someone writes a Pace >that points out a critical bug or missing feature in the format, and >a significant number of WG participants agree, we should miss our >deadline because we no longer have consensus on the *current draft*. First, let's differentiate "critical bug" from "missing feature". A critical bug can (should!) be brought to the list at any time, even after IETF Last Call. Until the IESG has signed off on the document, critical bugs are always fair game for discussion. Even after the RFC is issued, critical bugs can (should!) be fixed with new RFCs. As for "missing features", we have already been presented with literally dozens of missing features that the WG decided were not part of the Atom core. There are probably dozens more. We are explicitly putting those out of scope starting Monday because (a) the list is open-ended, (b) extensions to the core are fairly easy, and (c) the chance that a newly-discovered missing feature is really part of the *core* has been decreasing over the past year. Clearly, we will make mistakes in this document. There are very few finished protocols that don't have design errors (some of them critical) and/or missing features. If anyone thinks that we need more time to search for those, please propose a fixed date by which you think we will be done. We can then spend really fun time on the list talking about process issues and, if consensus is reached, Tim and I can ask for a charter revision with the new milestones. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Feb 2 22:58:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19667 for ; Wed, 2 Feb 2005 22:58:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133khZf032327; Wed, 2 Feb 2005 19:46:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j133khJ0032326; Wed, 2 Feb 2005 19:46:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from priv-edtnes40.telusplanet.net (outbound05.telus.net [199.185.220.224]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133kglD032311 for ; Wed, 2 Feb 2005 19:46:42 -0800 (PST) (envelope-from jeremy@jeremygray.ca) Received: from dora9 ([207.6.230.92]) by priv-edtnes40.telusplanet.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050203034635.YTC7841.priv-edtnes40.telusplanet.net@dora9>; Wed, 2 Feb 2005 20:46:35 -0700 Reply-To: From: "Jeremy Gray" To: "'Robert Sayre'" , "'Atom-Syntax'" Subject: RE: PaceEntriesElement Date: Wed, 2 Feb 2005 19:46:33 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050203030122.YMZQ18486.priv-edtnes46.telusplanet.net@dora9> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUJhsVHMDLIEcrUSsKJ0QHeT3cYiAAFOzfQAAHJW/A= Message-Id: <20050203034635.YTC7841.priv-edtnes40.telusplanet.net@dora9> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Here I go again. Replace "PaceEntryOrder" with "PaceEntriesElement". Ahh, the joy of looking at too many emails all at once. :) Jeremy -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Jeremy Gray Sent: Wednesday, February 02, 2005 7:01 PM To: 'Robert Sayre'; 'Atom-Syntax' Subject: RE: PaceEntriesElement 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 similar paces have been presented over time, and I must admit that I have not had the time I would like in order to review each in turn, so for the moment I'm going to make a few specific comments on PaceEntryOrder and will then try to find a bit of time this evening to re-review the other proposals before commenting in much more detail. The pace page on the wiki has a few things on which I'd like to comment, some could be typo-type errors, some could be conceptual bits I either don't understand or perhaps just don't agree with :). We'll see. On with the list: - The pace mentions atom:head in its 4.1.2 text, but my impression of the pace is that it would deprecate atom:head. - The pace, in its text for 4.1.2, mentions how a feed can have any number of entry elements. From the example, however, my impression of the pace would be that the feed must have one entries element, which can then in turn have any number of entry elements. I'll state my preference further in this email, but would appreciate some clarification on what is being proposed by the pace. - The pace, in its text for 4.1.2, states atom:contributor cardinality rules in the "MUST NOT" style text that conflict with the schema-style text There may be others worth noting, but I'm out of time for my initial review pass and must head out of the office. I'll try to do another scan, including a review of the other similar paces, later tonight if I have a bit of time. In the meantime, a few more "out there" pieces of food for thought in descending order of priority from my perspective: - merge and into , then merge child elements - add a linking construct that can support "item detail by reference", ala the following pseudo-markup example: ... ... ... ... ... ... Whether via or not, something like this would be very useful and powerful indeed. May, as-is or with further refinement, handle Antone's indirection desires. - remove , hang children directly from the parent. If not, at least rename it to match whatever "item"-related renaming might take place - simmer - enjoy I'll see what I can do about setting aside some time to more clearly document my thoughts, but figured it would at least be worthwhile providing the above comments and food for thought. Since I've really scrambled to type up this email and get out of the office, I've likely written some confusing or outright erroneous text. If anyone has any questions or comments, don't hesitate to contact me on-list or off. Even if I don't end up finding time to help with the production of actual pace text, I'm more than happy to discuss the involved issues. Jeremy Gray From owner-atom-syntax@mail.imc.org Wed Feb 2 22:58:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19685 for ; Wed, 2 Feb 2005 22:58:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133mFpU032405; Wed, 2 Feb 2005 19:48:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j133mFo6032404; Wed, 2 Feb 2005 19:48:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j133mFMl032391; Wed, 2 Feb 2005 19:48:15 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwXyX-0003l3-6l; Thu, 03 Feb 2005 03:48:13 +0000 Message-ID: <42019EFB.5040008@franklinmint.fm> Date: Wed, 02 Feb 2005 22:48:11 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: Call for final Paces for consideration: deadline imminent References: <42019301.20506@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > At 9:57 PM -0500 2/2/05, Robert Sayre wrote: > > First, let's differentiate "critical bug" from "missing feature". > Let's not. Let's differentiate "missing feature" from "critical missing feature". None of the "organization" Paces could easily be added to the core. If it were up to me, and I had to turn the draft in tomorrow, I would strike PaceHeadInEntry, because "it can easily be added later". > Clearly, we will make mistakes in this document. There are very few > finished protocols that don't have design errors (some of them critical) > and/or missing features. If anyone thinks that we need more time to > search for those, please propose a fixed date by which you think we will > be done. Our charter: --------------------------------------------------------- Goals and Milestones: Mar 05 Request Last Call for Atom feed format Mar 05 Request Last Call for Atom editing protocol --------------------------------------------------------- These two deadlines seem to be the ones at hand. I don't know whether "Mar 05" means March 1 or March 31, but let's say it means March 1. Clearly, the format is on track for that deadline, while the protocol is not. Since the chairs' proposed deadline for new Paces is February 7, please outline the process by which new text will make it in the draft between that date and March 1-31. Robert Sayre From owner-atom-syntax@mail.imc.org Wed Feb 2 23:46:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24584 for ; Wed, 2 Feb 2005 23:46:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j134cq7g035197; Wed, 2 Feb 2005 20:38:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j134cqX4035196; Wed, 2 Feb 2005 20:38:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j134cnrP035188; Wed, 2 Feb 2005 20:38:50 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <42019EFB.5040008@franklinmint.fm> References: <42019301.20506@franklinmint.fm> <42019EFB.5040008@franklinmint.fm> Date: Wed, 2 Feb 2005 20:37:28 -0800 To: mint@franklinmint.fm From: Paul Hoffman Subject: Re: Call for final Paces for consideration: deadline imminent Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:48 PM -0500 2/2/05, Robert Sayre wrote: >Paul Hoffman wrote: > >>At 9:57 PM -0500 2/2/05, Robert Sayre wrote: >> >>First, let's differentiate "critical bug" from "missing feature". >> > >Let's not. Let's differentiate "missing feature" from "critical >missing feature". Let's not. :-) Looking over the archives, there are certainly pockets of people in the WG who consider particular features that the WG has failed to reach consensus on as critical. It could be critical to their business model, to their picture of what blogging is, to their picture of what is needed to gain critical mass over RSS 2.0, to their picture of what is needed for extensibility, to their picture of what is needed to work with other parts of the XML alphabet soup, and so on. We do not have a way of defining "critical missing feature", and a group as diverse as this would be unable to come to consensus on such a definition in under a year, if then. This group would probably do what most IETF groups fighting with the same issue would do, namely cheat and make the "requirements" match the current document and piss everybody off in the process. > None of the "organization" Paces could easily be added to the core. Agree. But that's why there is one more round of consensus-gathering: to see if WG wants to do it, even if it isn't easy. >Our charter: >--------------------------------------------------------- >Goals and Milestones: >Mar 05 Request Last Call for Atom feed format >Mar 05 Request Last Call for Atom editing protocol >--------------------------------------------------------- > >These two deadlines seem to be the ones at hand. I don't know >whether "Mar 05" means March 1 or March 31, but let's say it means >March 1. Clearly, the format is on track for that deadline, while >the protocol is not. Maybe. >Since the chairs' proposed deadline for new Paces is February 7, >please outline the process by which new text will make it in the >draft between that date and March 1-31. Format draft: Feb. 7: All Paces must be complete Feb. 7: Begin formally discussing Paces so we can assess consensus Feb. 14: Finish discussion on Paces, assess consensus, ask editors to issue another draft Feb. 21ish: Get new draft Feb. 21ish: Start intensive editorial review March 1ish: Get another round of the draft including results of editorial review. March 1ish: Pass this to our AD in preparation for IETF Last Call Protocol draft: Feb 14ish: Renew discussion of outstanding technical and editorial issues in the protocol March 15ish: Try to close out draft March 31ish: Pass this to our AD in preparation for IETF Last Call All of these depend on what comes out of the WG process. Finding a critical bug in either spec could cause a delay because we need to agree on a fix and get another round of the draft. That's just fine. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Wed Feb 2 23:49:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24769 for ; Wed, 2 Feb 2005 23:49:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j134aROJ035141; Wed, 2 Feb 2005 20:36:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j134aR52035140; Wed, 2 Feb 2005 20:36:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j134aRn8035127 for ; Wed, 2 Feb 2005 20:36:27 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 2C07711C for ; Wed, 2 Feb 2005 20:36:22 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j134aJLf008307 for ; Wed, 2 Feb 2005 20:36:21 -0800 (PST) Date: Wed, 02 Feb 2005 20:36:20 -0800 From: Walter Underwood To: Atom WG Subject: Re: Call for final Paces for consideration: deadline imminent Message-ID: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: References: X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The charter says that Atom will work for archiving. We don't know that it will, and it hasn't been discussed for months. Is the current Atom spec sufficient for archiving? If not, we aren't done. wunder --On February 2, 2005 5:46:51 PM -0800 Paul Hoffman wrote: > > 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, and a couple of promises that "I'll write that up as a Pace soon". We need to finish soon in order to make our milestone, and I believe we can do so gracefully. > > On Monday, Feb. 7, the Working Group's final queue rotation will consist of all Paces open at that time. Any Paces that have obvious holes in them ("to be filled in later", "more needs to go here", etc.) will be ignored. We have had over a year of time here, and many weeks since the previous attempt to close things out. On Monday, Feb. 14, we will assess WG consensus and ask the document authors to put together a final draft. > > Note that this is not the last opportunity for work on the Atom format. For one thing, there are plenty of non-core extensions that folks have been mulling over; having the core draft finally finished will help those to emerge. Further, we need to do the final work on the protocol document. Also, during the formal IETF Last Call, discussion of the format draft will be welcome from everyone (including people who have not read any of the earlier drafts). > > 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. If your idea is appropriate as an extension, or is for something that is quite similar to something else that has explicitly gotten lack of consensus, please do not write a Pace. In the former case, please hold your extensions for a few weeks; in the latter case, please recognize that asking the WG to focus on something that they don't want will likely cause us to do a worse job at carefully reviewing things that we all want. > > So, if you have an incomplete Pace now, you have a few more days to complete it. Of course, everyone should feel free to continue talking about the current Paces now, and to continue to suggest editorial changes to the current Internet Draft. > > --Paul Hoffman, Director > --Internet Mail Consortium > > -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Feb 3 00:11:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26400 for ; Thu, 3 Feb 2005 00:11:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1352XJn036850; Wed, 2 Feb 2005 21:02:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1352XHS036849; Wed, 2 Feb 2005 21:02:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1352W5F036826 for ; Wed, 2 Feb 2005 21:02:32 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1940265 for atom-syntax@imc.org; Thu, 03 Feb 2005 16:02:23 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 16:02:15 +1100 Subject: Re: Call for final Paces for consideration: deadline imminent From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 3:36 PM, "Walter Underwood" wrote: > Is the current Atom spec sufficient for archiving? If not, we aren't done. We might need a new @rel value or two. Entries can be published in feeds which are then no longer updated. the spec supports this as is. what we don't have is any easy way of navigating through collections of archival feed documents. The simplest thing that could possibly work is allowing @rel="next" and @rel="previous". A current feed (as distinct from an archival collection), could point to the most recent archive with @rel="previous". It could also point to the start of the archive with @rel="start". I think it would also be interesting to codify a convention that /feed/head/link[@rel="archives"] points to another feed which contains one entry for each archival feed. If we do start pointing to feeds from entries and so forth, I think we might need to clarify the terms as previously discussed: what is currently an Atom Feed Document becomes an Atom Collection Document, while a "feed" is a special case of Atom Collection Document (no real differences in formatting, just in usage - ie. ongoing publishing). I'm off to write a Pace right now... e. From owner-atom-syntax@mail.imc.org Thu Feb 3 00:14:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26728 for ; Thu, 3 Feb 2005 00:14:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13524gd036807; Wed, 2 Feb 2005 21:02:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13524n8036806; Wed, 2 Feb 2005 21:02:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13523Mo036793; Wed, 2 Feb 2005 21:02:03 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwZ7x-0005TQ-W5; Thu, 03 Feb 2005 05:02:02 +0000 Message-ID: <4201B047.7010902@franklinmint.fm> Date: Thu, 03 Feb 2005 00:01:59 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: Call for final Paces for consideration: deadline imminent References: <42019301.20506@franklinmint.fm> <42019EFB.5040008@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > At 10:48 PM -0500 2/2/05, Robert Sayre wrote: > >> >> Let's not. Let's differentiate "missing feature" from "critical >> missing feature". > > Let's not. :-) Looking over the archives, there are certainly pockets of > people in the WG who consider particular features that the WG has failed > We do not have a way of defining "critical missing feature" Agree. However, we do have a way to identify things Atom sucks at. We can point at them and it will be obvious. These are not pie-in-the-sky scenarios, or semantic nirvana--they exist right now. If the WG decides these are out of bounds, so be it. Use cases here: http://www.imc.org/atom-syntax/mail-archive/msg12963.html 1.) Atom sucks at web forums (e.g. slashdot) 2.) Atom sucks at LiveJournal 3.) Atom sucks at Netflix Top 100 4.) Atom sucks at blogs with comments or trackbacks 5.) Atom sucks at anything with a representation of its own and collection membership I understand that Atom will not be perfect, but it's important to make it very obvious when something is left out intentionally. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 00:21:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27661 for ; Thu, 3 Feb 2005 00:21:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135BTI3037297; Wed, 2 Feb 2005 21:11:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j135BTDY037296; Wed, 2 Feb 2005 21:11:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135BSbt037290 for ; Wed, 2 Feb 2005 21:11:28 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwZH5-0005ff-1q for atom-syntax@imc.org; Thu, 03 Feb 2005 05:11:27 +0000 Message-ID: <4201B27C.6070003@franklinmint.fm> Date: Thu, 03 Feb 2005 00:11:24 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceMustBeWellFormed Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceMustBeWellFormed IMO, this Pace should be closed unless it is substantially rewritten before February 7th. The term "well-formed" has no place in this text, and should be replaced. This is what well-formed means: "[Definition: A textual object is a well-formed XML document if:] 1. Taken as a whole, it matches the production labeled document. 2. It meets all the well-formedness constraints given in this specification. 3. Each of the parsed entities which is referenced directly or indirectly within the document is well-formed." Stretching, extending, or profiling the XML specification and/or RFC3023 to lend weight to the text is totally inappropriate. All we can do is say "MUST" and define our own terms to the extent that we can. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 00:29:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28481 for ; Thu, 3 Feb 2005 00:29:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135LqNl038417; Wed, 2 Feb 2005 21:21:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j135LqgB038416; Wed, 2 Feb 2005 21:21:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135Lotf038404 for ; Wed, 2 Feb 2005 21:21:51 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1940402 for atom-syntax@imc.org; Thu, 03 Feb 2005 16:21:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 16:21:42 +1100 Subject: Re: Call for final Paces for consideration: deadline imminent From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4201B047.7010902@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 4:01 PM, "Robert Sayre" wrote: > 4.) Atom sucks at blogs with comments or trackbacks > 5.) Atom sucks at anything with a representation of its own and > collection membership e. From owner-atom-syntax@mail.imc.org Thu Feb 3 00:47:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA29982 for ; Thu, 3 Feb 2005 00:47:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135bHfI039184; Wed, 2 Feb 2005 21:37:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j135bHIc039183; Wed, 2 Feb 2005 21:37:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135bGF2039177 for ; Wed, 2 Feb 2005 21:37:17 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so24071rne for ; Wed, 02 Feb 2005 21:37:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=cM+WITVTx6pxvUZFoSUqg4aWUmYxqLJALdCzDmESHjUL9W+gddlAe5DnzdfK40uha4Je9vz1ENgHRCVSXRG4Jmo5eZKInzZmS2bzme9Cfa6JuYZm34Oql7hCf29zHKCt5y3SDf1ZIrfDGyBjZk7rsQxQymDccD+T7cnGLPFHlmI= Received: by 10.38.59.3 with SMTP id h3mr40721rna; Wed, 02 Feb 2005 21:36:15 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 21:36:15 -0800 (PST) Message-ID: <2bcdc7c405020221365a9e477d@mail.gmail.com> Date: Wed, 2 Feb 2005 21:36:15 -0800 From: James Snell Reply-To: James Snell To: Robert Sayre Subject: Re: PaceEntriesElement Cc: Atom-Syntax In-Reply-To: <42016CAA.2000000@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <42016CAA.2000000@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert, I can see what you're trying to accomplish with this, but I have a number of concerns. First, this proposal is trying to muddle together two distinctly different concepts: 1. A Feed is either a container of Entries or a Feed contains a container of Entries 2. A Feed is a type of Entry I don't think there is any value in mixing these two into a single Pace because they each can be argued/rejected/adopted on their own merits. Splitting them into two separate Pace's would probably be a better approach. That said, please allow me to offer my opinion on both: First, I tend to view a Feed as the container for entries as opposed to a Feed having a container of entries as a property. The reason? I think it makes the model cleaner and simpler, and makes the syntax a bit more compact. Despite the rationale you give, I just don't see how introducing an entries element significantly improves the Atom format. On the second point, I understand why someone would want to have hierarchical feeds, I just don't agree that it needs to be something built into the Atom core. If we can agree that a Feed is a collection of Entries, an extension can be written that defines a Feed as a type of Entry. Doing so keeps the core syntax simple, while still allowing for the cases you are trying to enable. Further, I am not convinced that hierarchical feeds are going to be anything more than a limited-use edge case. Thoughts? On Wed, 02 Feb 2005 19:13:30 -0500, Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceEntriesElement > > Abstract > ------------------------- > Remove atom:head, group entries with atom:entries instead. Allow feeds > to contain atom:summary and atom:content (Folders are Resources Too!). > > Use cases: http://www.imc.org/atom-syntax/mail-archive/msg12963.html > > Status > ------------------------- > Open > > Rationale > ------------------------- > Making a feed document strictly hierarchical and recursive solves a > number of problems that have been previously attacked in a piecemeal > fashion: > > 1. XML containment relates feed and entry metadata to the data being > described, thereby defining a consistent model for future extension > elements; > > 2. Multiple feeds can be aggregated and presented using a single data > format without having to modify the entries within those feeds to > incorporate their original feed metadata; > > 3. Digital signatures can be safely applied to feeds and entries > without needing special-case exceptions on how to recreate the signature > after aggregation; > > 4. Simplifies description of the Atom syndication format to containers > (feed, entries, entry, content) and metadata that targets its own parent > (feed or entry). > > 5. Allows Hierarchical feeds, comments. > > 6. Practically zero changes for format05 feeds in the simple case. > Entry elements are wrapped with atom:entries instead of headers being > wrapped with atom:head. > > 7. Differentiates elements lower in a hierarchy (collection members) > from metadata. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 01:04:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01291 for ; Thu, 3 Feb 2005 01:04:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135ti0a040091; Wed, 2 Feb 2005 21:55:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j135titL040090; Wed, 2 Feb 2005 21:55:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j135tgVO040084 for ; Wed, 2 Feb 2005 21:55:43 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1940697 for atom-syntax@imc.org; Thu, 03 Feb 2005 16:55:43 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 16:55:35 +1100 Subject: PaceCollection From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 Conflicting Proposals == none == Rationale == The term "feed" has generally held the special meaning of "the collection of entries which were recently published, and into which new entries will also be published, with older entries being removed sliding window style" (or something like that) Which has meant it has been a pain to refer to Atom Feed Documents which don't obey that semantic, instead being (say) an archive of all posts within a specific period of time (eg. June 2004). A given resource (eg. the June 2004 archive) could be said to be both an Atom Feed document, but also ''not'' be a "feed". Confusing. Atom Feed Documents are properly collections, of which "feeds" are just one semantic. Other semantics for Atom Collection Documents include "archives", "directory", "comments", "trackbacks", "pings", "parts", "versions", and so on. == Proposal == Rename the top level element for Atom Feed Documents to "atom:collection", and rename Atom Feed Document to Atom Collection Document. {{{ no spec text -- this is really just a job for the editor, i hope. * s/atom:feed/atom:collection/ * s/Atom Feed Document/Atom Collection Document/ }}} == Impacts == none. it's just a name change. == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Thu Feb 3 01:17:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02430 for ; Thu, 3 Feb 2005 01:17:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136AFfc043010; Wed, 2 Feb 2005 22:10:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136AFQQ043009; Wed, 2 Feb 2005 22:10:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136AEob042967 for ; Wed, 2 Feb 2005 22:10:14 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so29361rne for ; Wed, 02 Feb 2005 22:10:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=D4hfrgNXvX3wI7GCFIdZk8g1vvi6Vid5FF6bKBov26/cAkBfGVrgUHckMDuadXYOOwSTnkAxuRDTCHTaO/TBne2ikhru2IyvfoFQLXnPUCvfKIRgyzuITPPhDHhQ0kJCL2xNiyyFooC2B1ccHRxcA/2nlFcrEfCGylivl63A+tY= Received: by 10.38.59.3 with SMTP id h3mr54710rna; Wed, 02 Feb 2005 22:09:10 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 22:09:10 -0800 (PST) Message-ID: <2bcdc7c4050202220947793133@mail.gmail.com> Date: Wed, 2 Feb 2005 22:09:10 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bear with me on this, I'm just throwing it out for the sake of the conversation. 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 need then is a just container for feeds. One that encapsulates by reference rather than by direct containment. Perhaps a top level document like the following would be sufficient?) Archive Title Archive Title Archive Title Archive Title Just a single new @rel value for the link element in an atom feed head can then be created that points to this archive index document. The nice thing about this approach is that it can be done completely as an extension to the core rather than as a modification of the core as it currently exists. In other words, an "Atom Archive Format" RFC can be written up separately from the core to handle the archive case. Thoughts? On Thu, 03 Feb 2005 16:02:15 +1100, Eric Scheid wrote: > > On 3/2/05 3:36 PM, "Walter Underwood" wrote: > > > Is the current Atom spec sufficient for archiving? If not, we aren't done. > > We might need a new @rel value or two. > > Entries can be published in feeds which are then no longer updated. the spec > supports this as is. what we don't have is any easy way of navigating > through collections of archival feed documents. > > The simplest thing that could possibly work is allowing @rel="next" and > @rel="previous". > > A current feed (as distinct from an archival collection), could point to the > most recent archive with @rel="previous". It could also point to the start > of the archive with @rel="start". > > I think it would also be interesting to codify a convention that > /feed/head/link[@rel="archives"] points to another feed which contains one > entry for each archival feed. > > If we do start pointing to feeds from entries and so forth, I think we might > need to clarify the terms as previously discussed: what is currently an Atom > Feed Document becomes an Atom Collection Document, while a "feed" is a > special case of Atom Collection Document (no real differences in formatting, > just in usage - ie. ongoing publishing). I'm off to write a Pace right > now... > > e. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 01:21:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02763 for ; Thu, 3 Feb 2005 01:21:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136CRul043920; Wed, 2 Feb 2005 22:12:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136CRDh043919; Wed, 2 Feb 2005 22:12:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136CNV6043861 for ; Wed, 2 Feb 2005 22:12:24 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so29746rne for ; Wed, 02 Feb 2005 22:12:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=CBL0xPxuOdawuA0juhlQLS3xSbwgMgN6c9qZ29uaqYRTkdjt0AUtLbspH0Y5ILQmSD0AAfgIX46vgJ2cNEbQE7ScLNlZhqOOW9KIETdsior9PHb0B4uLLvL/t4DzuLCXvYKGvELkUxRH25n2TYTtB4GOerkHe1fSJ8X0DYgGmp4= Received: by 10.38.98.4 with SMTP id v4mr167302rnb; Wed, 02 Feb 2005 22:12:18 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 22:12:18 -0800 (PST) Message-ID: <2bcdc7c405020222121ddff96c@mail.gmail.com> Date: Wed, 2 Feb 2005 22:12:18 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Re: PaceCollection Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. A name change of the top level element accomplishes nothing. On Thu, 03 Feb 2005 16:55:35 +1100, Eric Scheid wrote: > > > 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 Conflicting Proposals == > > none > > == Rationale == > > The term "feed" has generally held the special meaning of "the collection of > entries which were recently published, and into which new entries will also > be published, with older entries being removed sliding window style" (or > something like that) > > Which has meant it has been a pain to refer to Atom Feed Documents which > don't obey that semantic, instead being (say) an archive of all posts within > a specific period of time (eg. June 2004). A given resource (eg. the June > 2004 archive) could be said to be both an Atom Feed document, but also > ''not'' be a "feed". Confusing. > > Atom Feed Documents are properly collections, of which "feeds" are just one > semantic. Other semantics for Atom Collection Documents include "archives", > "directory", "comments", "trackbacks", "pings", "parts", "versions", and so > on. > > == Proposal == > > Rename the top level element for Atom Feed Documents to "atom:collection", > and rename Atom Feed Document to Atom Collection Document. > > {{{ > no spec text -- this is really just a job for the editor, i hope. > > * s/atom:feed/atom:collection/ > * s/Atom Feed Document/Atom Collection Document/ > }}} > > == Impacts == > > none. it's just a name change. > > == Notes == > > ---- > CategoryProposals > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 01:35:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04346 for ; Thu, 3 Feb 2005 01:35:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136TwMU050305; Wed, 2 Feb 2005 22:29:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136TwLj050304; Wed, 2 Feb 2005 22:29:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136Tu0x050273 for ; Wed, 2 Feb 2005 22:29:57 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so32338rne for ; Wed, 02 Feb 2005 22:29:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=bm7bay+wbUh8xPIJoHqmhsXT/+jyXIHIh37DPpz0xsH8Z9u7AtNEqXxIylrYaGFSeLOOFzKDNBYzSq4KYVj5ZEGsQrXm51RfwzfOzuWZqzXRv5zjB2VUSs7Z7if+f9PBa7nROMeKlGYRFWfg9qiO5VfBO4j/v3qSUxdieQpuLl8= Received: by 10.38.151.67 with SMTP id y67mr76666rnd; Wed, 02 Feb 2005 22:29:53 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 22:29:53 -0800 (PST) Message-ID: <2bcdc7c40502022229a4da689@mail.gmail.com> Date: Wed, 2 Feb 2005 22:29:53 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Re: Call for final Paces for consideration: deadline imminent Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4201B047.7010902@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +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 single document. On Thu, 03 Feb 2005 16:21:42 +1100, Eric Scheid wrote: > > On 3/2/05 4:01 PM, "Robert Sayre" wrote: > > > 4.) Atom sucks at blogs with comments or trackbacks > > 5.) Atom sucks at anything with a representation of its own and > > collection membership > > > > > > e. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 01:37:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04623 for ; Thu, 3 Feb 2005 01:37:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136Rp8S049567; Wed, 2 Feb 2005 22:27:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136RpTo049566; Wed, 2 Feb 2005 22:27:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136Rn2r049471 for ; Wed, 2 Feb 2005 22:27:50 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1940907 for atom-syntax@imc.org; Thu, 03 Feb 2005 17:27:42 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 17:27:33 +1100 Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c4050202220947793133@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 5:09 PM, "James Snell" 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 > need then is a just container for feeds. One that encapsulates by > reference rather than by direct containment. Perhaps a top level > document like the following would be sufficient?) > > > > > Archive Title > Your example format doesn't include dates for when the referenced items were last updated, nor unique IDs for disambiguation, etc etc ... why not instead: The 2001 Archive of My Big Fat Fenugreek Blog [...] January 2001 Archive 208 posts over 19 days [...] February 2001 Archive 311 posts over 23 days [...] > Just a single new @rel value for the link element in an atom feed head > can then be created that points to this archive index document. > > > > > > [...] > this is exactly what I had in mind with PaceCollections. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 01:42:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05129 for ; Thu, 3 Feb 2005 01:42:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136aACh053792; Wed, 2 Feb 2005 22:36:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136aAWv053791; Wed, 2 Feb 2005 22:36:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136a8x9053715 for ; Wed, 2 Feb 2005 22:36:09 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1940932 for atom-syntax@imc.org; Thu, 03 Feb 2005 17:36:10 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 17:36:01 +1100 Subject: Re: PaceCollection From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c405020222121ddff96c@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 5:12 PM, "James Snell" wrote: > -1. A name change of the top level element accomplishes nothing. It eliminates confusion when people talk of "an atom feed". The unpleasant reality is that Atom will succeed in the real world depending on how well people understand what it's all about, and eliminating confusion and opportunities for mis-assumptions is part of that. Talking about, and thinking about, archives for atom would have been so much simpler and obvious if the main document was called an Atom Collection Document. Making collections of trackbacks and comments and pings and versions and what have you could be done without the mental friction of referring to them as "feeds". It's the same broad problem we have with three distinctly different attributes with different restrictions all being named "type". e. From owner-atom-syntax@mail.imc.org Thu Feb 3 01:53:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05949 for ; Thu, 3 Feb 2005 01:53:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136kDE9058925; Wed, 2 Feb 2005 22:46:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136kD8E058924; Wed, 2 Feb 2005 22:46:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136kCBk058871 for ; Wed, 2 Feb 2005 22:46:13 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so34686rne for ; Wed, 02 Feb 2005 22:46:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=OScTU+tw90pYP4wRV3YDQZrhOJuHdv4LLMozBcZkTEKgW3eqJl/3fQgqfSKOkEkEt8Iux1oa9UQTlB2j2no7T/7SqWJ/6R3fPek0pviotsy9vZFF0iM0O0RShxV49i9JPsAUO94tXP+7iol62S17wsx/PUqLLZZBxXZNjCCKWWs= Received: by 10.38.151.59 with SMTP id y59mr315600rnd; Wed, 02 Feb 2005 22:46:09 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 22:46:09 -0800 (PST) Message-ID: <2bcdc7c4050202224649a9fad@mail.gmail.com> Date: Wed, 2 Feb 2005 22:46:09 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c4050202220947793133@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Comments below.. On Thu, 03 Feb 2005 17:27:33 +1100, Eric Scheid wrote: > > On 3/2/05 5:09 PM, "James Snell" 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 > > need then is a just container for feeds. One that encapsulates by > > reference rather than by direct containment. Perhaps a top level > > document like the following would be sufficient?) > > > > > > > > > > Archive Title > > > > Your example format doesn't include dates for when the referenced items were > last updated, nor unique IDs for disambiguation, etc etc ... why not > instead: > > > > The 2001 Archive of My Big Fat Fenugreek Blog > [...] > > > January 2001 Archive > 208 posts over 19 days > > [...] > > > February 2001 Archive > 311 posts over 23 days > > [...] > > > This is better. I guess I just hadn't grok'd the idea of using entries to reference feeds, but now that I see the angle brackets I get it. (perhaps I just need some coffee). As long as it is legal for an "alternate" link to reference a feed document, this works perfectly. I like the containment-by-reference approach. Best of all, this could be accomplished without requiring any changes to the existing core.. > > > Just a single new @rel value for the link element in an atom feed head > > can then be created that points to this archive index document. > > > > > > > > > > > > [...] > > > > this is exactly what I had in mind with PaceCollections. > Well, from your Pace: "Atom Feed Documents are properly collections, of which "feeds" are just one semantic. Other semantics for Atom Collection Documents include "archives", "directory", "comments", "trackbacks", "pings", "parts", "versions", and so on." If we define a "feed" as a collection of entries, archives, directories, comments, trackbacks, pings, parts, versions, and so forth, then the name "feed" is descriptive enough to get the point across. I'm not sure I follow the connection between PaceCollection and the archive @rel attribute. Did I miss something? > e. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 02:01:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08198 for ; Thu, 3 Feb 2005 02:01:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136tPer064051; Wed, 2 Feb 2005 22:55:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j136tPw7064050; Wed, 2 Feb 2005 22:55:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j136tO6Z064012 for ; Wed, 2 Feb 2005 22:55:24 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so35961rne for ; Wed, 02 Feb 2005 22:55:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YLqiCI+ZiJPr9j3XA1+uccJENu1+lwV3IiWfV23ssGQsHdnYk9l8bYepU2hB5xjxDfUvDpxQ9hHou2hwODhaLCztbIB81MseT5/egjtfQzHHpaN3EMCdRloANe5If0VOe9BLgJlVXJsHCM5hC9DOGGcJTcIFUjK5WSPfWiskP5c= Received: by 10.38.90.15 with SMTP id n15mr24935rnb; Wed, 02 Feb 2005 22:55:19 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 22:55:19 -0800 (PST) Message-ID: <2bcdc7c4050202225559e7bc57@mail.gmail.com> Date: Wed, 2 Feb 2005 22:55:19 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Re: PaceCollection Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c405020222121ddff96c@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > It eliminates confusion when people talk of "an atom feed". The unpleasant > reality is that Atom will succeed in the real world depending on how well > people understand what it's all about, and eliminating confusion and > opportunities for mis-assumptions is part of that. > > Talking about, and thinking about, archives for atom would have been so much > simpler and obvious if the main document was called an Atom Collection > Document. Making collections of trackbacks and comments and pings and > versions and what have you could be done without the mental friction of > referring to them as "feeds". It's the same broad problem we have with three > distinctly different attributes with different restrictions all being named > "type". Yeah, but it's just a name. It the name was changed, folks would still have to go back to the spec to figure out what it is a collection of. Atom is first and foremost a "feed format" that "enables syndication". As such, it just happens to be a "collection", but that is secondary. The name feed is descriptive of it's purpose, which, in my opinion, is far more important. In any case, we're talking about something as simple as the name of a single element. I just don't see any real technical value in changing it's name. It doesn't make processing any easier. It doesn't change any of the functional semantics. It doesn't address any critical bugs in the design. It just doesn't do anything. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 02:12:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18831 for ; Thu, 3 Feb 2005 02:12:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1375wgJ067713; Wed, 2 Feb 2005 23:05:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1375wRe067712; Wed, 2 Feb 2005 23:05:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from afc.gov.au (mail.afc.gov.au [203.202.130.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1375udF067683 for ; Wed, 2 Feb 2005 23:05:57 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [192.168.25.1] (HELO [192.168.45.41]) by afc.gov.au (CommuniGate Pro SMTP 4.2.8) with ESMTP id 1941059 for atom-syntax@imc.org; Thu, 03 Feb 2005 18:05:58 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 18:05:49 +1100 Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c4050202224649a9fad@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 5:46 PM, "James Snell" wrote: > Well, from your Pace: "Atom Feed Documents are properly collections, > of which "feeds" are just one semantic. Other semantics for Atom > Collection Documents include "archives", "directory", "comments", > "trackbacks", "pings", "parts", "versions", and so on." hmmm ... you've caught myself mid-renaming. I can see how that can be confusing. The first mention of Atom Feed Documents there would be the past tense sense ... what I meant was: The thing we currently call "Atom Feed Documents" are properly [...] Pace updated, thanks. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 02:59:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26557 for ; Thu, 3 Feb 2005 02:59:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j137odod083167; Wed, 2 Feb 2005 23:50:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j137odDE083165; Wed, 2 Feb 2005 23:50:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j137ocXM083144 for ; Wed, 2 Feb 2005 23:50:38 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so43419rne for ; Wed, 02 Feb 2005 23:50:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=kDkohC7a88XopeEpwpM378TIRIpdgd3zPjZ2FqMielTa2et5XIzFZlU4/ssLpHLeIqyXlPJAbukparM/UQzRRhRgHTBUBlR8gkB3PfflNv8+9XhAYltIzgxBSuUKpH+amPlP83z189u7S4UxYe0+dbMhiGOK4tHPfOtNvB8qnpE= Received: by 10.38.151.59 with SMTP id y59mr343121rnd; Wed, 02 Feb 2005 23:50:36 -0800 (PST) Received: by 10.38.72.20 with HTTP; Wed, 2 Feb 2005 23:50:36 -0800 (PST) Message-ID: <2bcdc7c405020223506f192155@mail.gmail.com> Date: Wed, 2 Feb 2005 23:50:36 -0800 From: James Snell Reply-To: James Snell To: Atom Syntax Subject: ServiceElement and other matters Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 various conversations and debates that may have gone on previously regarding any single part of the spec. In reading through the spec, several things stick out: 1. Service Construct. While I understand what the Service Construct is trying to do, and I agree that it is needed, it does not seem to me to be something that rightfully belongs in the "core" Atom syntax. Rather, it seems better placed as an Atom syntax extension introduced by the Protocol specification. The rationale is simple: The Protocol spec should deal with all service related issues, including any extensions to the core that are necessary to communicate protocol related information. If I were putting this stuff together, I would move the Service Construct to the protocol spec. 2. Entry id's. Ok, so they are supposed to be "universally unique". That's all good and fine. But what if... hypothetically... my Atom reader gets two copies of the same Entry with different metadata. They are the same entry because they have the same id. One of the versions of the entry differs from the other in that some feed aggregator somewhere added some additional pieces of metadata to it. Do I: a) silently reject one of the entries, b) merge the metadata of the two entry instances into a single logical entry, c) throw up on the user. Case in point where this might be an issue: Suppose an entry in a feed that references a standalone entry document for the same entry. My Entry uri:abc uri:abc Hello There Is this legal? If it is, how should clients handle this situation? Do the two separate entry elements merge to form a single logical entry or does one replace the other? 3. I know this has been discussed elsewhere because I've seen a couple of recent posts about it. The version attribute just seems hokey. It doesn't add any value beyond what the XML namespace already provides. Just one guys opinion. Take it for what it's worth. 4. What the heck is an introspection document? I actually do know what it is, but the current doc doesn't say. This needs to be fleshed out obviously. Of course, if #1 above is addressed, this ceases to be a problem. :-) This is what I came up with on my first full read through of the -05 draft. Maybe more later. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 03:27:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28739 for ; Thu, 3 Feb 2005 03:27:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138IDBr094374; Thu, 3 Feb 2005 00:18:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j138ID3l094373; Thu, 3 Feb 2005 00:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138ICs6094361 for ; Thu, 3 Feb 2005 00:18:12 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwcBi-0007MD-NW; Thu, 03 Feb 2005 08:18:06 +0000 Message-ID: <4201DE3C.2040703@franklinmint.fm> Date: Thu, 03 Feb 2005 03:18:04 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snell CC: Eric Scheid , Atom Syntax Subject: sub feeds (was Re: Call for final Paces for consideration: deadline imminent) References: <4201B047.7010902@franklinmint.fm> <2bcdc7c40502022229a4da689@mail.gmail.com> In-Reply-To: <2bcdc7c40502022229a4da689@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd just like to point out that this is not a new feature. Any half-decent aggregator already does this for you with grouped feeds. For example, in NetNewsWire, you can click on folder. "Planet" feeds simulate this feature badly due to limitations in existing formats, but users like them because it eliminates lots of clerical work. Robert Sayre James Snell wrote: > +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 single document. Yes, sub-feeds can be nested by reference. Whether or not it's a net-win is probably variable. James Snell wrote: > This is better. I guess I just hadn't grok'd the idea of using > entries to reference feeds, but now that I see the angle brackets I > get it. Yes, feeds are entries. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 03:27:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28760 for ; Thu, 3 Feb 2005 03:27:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138MEFl095838; Thu, 3 Feb 2005 00:22:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j138MEG8095837; Thu, 3 Feb 2005 00:22:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138MC8U095823 for ; Thu, 3 Feb 2005 00:22:13 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 3 Feb 2005 21:22:59 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 19:22:10 +1100 Subject: Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4201DE3C.2040703@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 7:18 PM, "Robert Sayre" wrote: >> This is better. I guess I just hadn't grok'd the idea of using >> entries to reference feeds, but now that I see the angle brackets I >> get it. > > Yes, feeds are entries. no, feeds are collections, entries describe resources, and while feeds are also resources that only means that entries can describe feeds, not actually be feeds. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 03:28:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28800 for ; Thu, 3 Feb 2005 03:28:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138J9IV094685; Thu, 3 Feb 2005 00:19:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j138J9io094684; Thu, 3 Feb 2005 00:19:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138J7Zr094505 for ; Thu, 3 Feb 2005 00:19:08 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Thu, 3 Feb 2005 21:19:23 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Feb 2005 19:18:04 +1100 Subject: Re: ServiceElement and other matters From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c405020223506f192155@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 3/2/05 6:50 PM, "James Snell" wrote: > 2. Entry id's. Ok, so they are supposed to be "universally unique". > That's all good and fine. But what if... hypothetically... my Atom > reader gets two copies of the same Entry with different metadata. > They are the same entry because they have the same id. One of the > versions of the entry differs from the other in that some feed > aggregator somewhere added some additional pieces of metadata to it. > Do I: a) silently reject one of the entries, b) merge the metadata of > the two entry instances into a single logical entry, c) throw up on > the user. The thinking so far has been that you would discard the one which has the older datestamp. If the values are equal, then any differences were not considered "significant" by the publisher, and so you can silently discard either one. You wouldn't merge the versions, apparently. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 03:40:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29821 for ; Thu, 3 Feb 2005 03:40:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138WbAX099697; Thu, 3 Feb 2005 00:32:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j138Wb2o099695; Thu, 3 Feb 2005 00:32:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138WaW7099685 for ; Thu, 3 Feb 2005 00:32:36 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so49964rne for ; Thu, 03 Feb 2005 00:32:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=RZW1Emmg+M1FJ1ZuHyQFSoQbfft9W3bLXKtEGW77g4rbzGsWCrAYRL36rPt2RreMj3NOMllUw7aAUMtlfQlZFaKsIZYDDqkVqz9VeugoR1ZIrXdPX/3kxiN5WgbE+RhibVfeTrT5bm1KIM3B9GqKhKEZS1WUINdOXHvBoR6ahrY= Received: by 10.38.13.77 with SMTP id 77mr67012rnm; Thu, 03 Feb 2005 00:32:36 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 00:32:36 -0800 (PST) Message-ID: <2bcdc7c405020300327277f91e@mail.gmail.com> Date: Thu, 3 Feb 2005 00:32:36 -0800 From: James Snell Reply-To: James Snell To: Eric Scheid Subject: Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent) Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <4201DE3C.2040703@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 03 Feb 2005 19:22:10 +1100, Eric Scheid wrote: > > On 3/2/05 7:18 PM, "Robert Sayre" wrote: > > >> This is better. I guess I just hadn't grok'd the idea of using > >> entries to reference feeds, but now that I see the angle brackets I > >> get it. > > > > Yes, feeds are entries. > > no, feeds are collections, entries describe resources, and while feeds are > also resources that only means that entries can describe feeds, not actually > be feeds. > +1 on "entries can describe feeds, not actually be feeds". An entry can reference a feed, but is not the feed itself. > e. > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 04:00:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01349 for ; Thu, 3 Feb 2005 04:00:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138qehb006693; Thu, 3 Feb 2005 00:52:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j138qeuk006692; Thu, 3 Feb 2005 00:52:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j138qdow006683 for ; Thu, 3 Feb 2005 00:52:39 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 31123 invoked by uid 17064); 3 Feb 2005 08:52:39 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.10.189]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 3 Feb 2005 08:52:39 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <58a1cf357f0db619ab9a821f06735201@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: ServiceElement and other matters Date: Thu, 3 Feb 2005 09:52:10 +0100 To: James Snell , Eric Scheid X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In RDF/model terms the id is a functional property relating an Entry/Head and a resource (see my AtomOWL pace) It is not strictly an identity property (which would require it to be functional, inverse functional, symmetric and transitive) This therefore gives you no allowance to merge the entries. You can sort them by date or other ways if you wish though. Henry On 3 Feb 2005, at 09:18, Eric Scheid wrote: > On 3/2/05 6:50 PM, "James Snell" wrote: > >> 2. Entry id's. Ok, so they are supposed to be "universally unique". >> That's all good and fine. But what if... hypothetically... my Atom >> reader gets two copies of the same Entry with different metadata. >> They are the same entry because they have the same id. One of the >> versions of the entry differs from the other in that some feed >> aggregator somewhere added some additional pieces of metadata to it. >> Do I: a) silently reject one of the entries, b) merge the metadata of >> the two entry instances into a single logical entry, c) throw up on >> the user. > > The thinking so far has been that you would discard the one which has > the > older datestamp. If the values are equal, then any > differences were not considered "significant" by the publisher, and so > you > can silently discard either one. > > You wouldn't merge the versions, apparently. > > e. > From owner-atom-syntax@mail.imc.org Thu Feb 3 04:14:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02301 for ; Thu, 3 Feb 2005 04:14:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13942wS010381; Thu, 3 Feb 2005 01:04:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13942f7010380; Thu, 3 Feb 2005 01:04:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net (mail11.svc.cra.dublin.eircom.net [159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j13941bX010340 for ; Thu, 3 Feb 2005 01:04:01 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 17991 messnum 15258682 invoked from network[213.94.211.166/mail2.newbay.com]); 3 Feb 2005 09:03:55 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail11.svc.cra.dublin.eircom.net (qp 17991) with SMTP; 3 Feb 2005 09:03:55 -0000 Message-ID: <4201E8F9.1030702@dehora.net> Date: Thu, 03 Feb 2005 09:03:53 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceCollection References: <2bcdc7c405020222121ddff96c@mail.gmail.com> <2bcdc7c4050202225559e7bc57@mail.gmail.com> In-Reply-To: <2bcdc7c4050202225559e7bc57@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: > In any case, we're talking about something as simple as the name of a > single element. I just don't see any real technical value in changing > it's name. It doesn't make processing any easier. It doesn't change > any of the functional semantics. It doesn't address any critical bugs > in the design. It just doesn't do anything. I don't think asking or looking for "technical value" is that relevant here. Names are important [witness the arguments over the name "RSS"]. In markup, element naming tends to matter. In this case replacing atom:feed with atom:collection doesn't help me personally understand the format better - I'm 0 on PaceCollection. cheers Bill From owner-atom-syntax@mail.imc.org Thu Feb 3 04:25:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02979 for ; Thu, 3 Feb 2005 04:25:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j139GVB5014536; Thu, 3 Feb 2005 01:16:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j139GVF0014533; Thu, 3 Feb 2005 01:16:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j139GUKU014504 for ; Thu, 3 Feb 2005 01:16:31 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 01EA54F418; Thu, 3 Feb 2005 04:16:26 -0500 (EST) Message-Id: <6.0.0.20.2.20050203172956.0409b950@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Thu, 03 Feb 2005 17:30:50 +0900 To: Danny Ayers , Graham From: Martin Duerst Subject: Re: tagline -> subtitle Cc: Atom Syntax In-Reply-To: <1f2ed5cd050202095963588da2@mail.gmail.com> References: <71234c9ab7c316582d9da9c077b76457@mac.com> <1f2ed5cd050202095963588da2@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit At 02:59 05/02/03, Danny Ayers wrote: > >+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+. +1 from me, too. I think subtitle is also easier to get for non-English speakers than 'tagline'. Regards, Martin. From owner-atom-syntax@mail.imc.org Thu Feb 3 04:38:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03873 for ; Thu, 3 Feb 2005 04:38:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j139MEXG016777; Thu, 3 Feb 2005 01:22:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j139ME3H016775; Thu, 3 Feb 2005 01:22:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j139MDr9016732 for ; Thu, 3 Feb 2005 01:22:14 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 89061 messnum 1894643 invoked from network[213.94.211.166/mail2.newbay.com]); 3 Feb 2005 09:22:07 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail02.svc.cra.dublin.eircom.net (qp 89061) with SMTP; 3 Feb 2005 09:22:07 -0000 Message-ID: <4201ED3C.9000205@dehora.net> Date: Thu, 03 Feb 2005 09:22:04 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: Re: PaceEntriesElement References: <42016CAA.2000000@franklinmint.fm> In-Reply-To: <42016CAA.2000000@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > 1. XML containment relates feed and entry metadata to the data being > described, thereby defining a consistent model for future extension > elements; I'm dubious about this claim. XML containment has even less semantic grist to it than UML aggregation. My sense is when we get down to it, we'll end up defining explicitly what containment means and there will be multiple meanings. > 2. Multiple feeds can be aggregated and presented using a single data > format without having to modify the entries within those feeds to > incorporate their original feed metadata; That sounds like a win. > 3. Digital signatures can be safely applied to feeds and entries > without needing special-case exceptions on how to recreate the signature > after aggregation; Ultimately I'll defer to an expert on this, but I'd like to see an example of a special case that is circumvented ;) > 6. Practically zero changes for format05 feeds in the simple case. > Entry elements are wrapped with atom:entries instead of headers being > wrapped with atom:head. Why not make make atom:head an atom:entry? > 7. Differentiates elements lower in a hierarchy (collection members) > from metadata. See my comment on 1. I think it only differentiates when we say it does, and this already suggests two containment 'semantics' (ie, there'll be an if/else in the code). Btw, this sounds like it's going to work like RDF/XML striping. cheers Bill From owner-atom-syntax@mail.imc.org Thu Feb 3 05:02:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05802 for ; Thu, 3 Feb 2005 05:02:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j139tPMB028647; Thu, 3 Feb 2005 01:55:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j139tPoV028646; Thu, 3 Feb 2005 01:55:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j139tO95028611 for ; Thu, 3 Feb 2005 01:55:25 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 99937 messnum 4158490 invoked from network[213.94.211.166/mail2.newbay.com]); 3 Feb 2005 09:55:19 -0000 Received: from mail2.newbay.com (HELO ?192.168.213.135?) (213.94.211.166) by mail00.svc.cra.dublin.eircom.net (qp 99937) with SMTP; 3 Feb 2005 09:55:19 -0000 Message-ID: <4201F504.5030609@dehora.net> Date: Thu, 03 Feb 2005 09:55:16 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceMustBeWellFormed References: <4201B27C.6070003@franklinmint.fm> In-Reply-To: <4201B27C.6070003@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > > http://www.intertwingly.net/wiki/pie/PaceMustBeWellFormed > [...] > Stretching, extending, or profiling the XML specification and/or RFC3023 > to lend weight to the text is totally inappropriate. All we can do is > say "MUST" and define our own terms to the extent that we can. If, - 6.2 was dropped and probably - the first sentence of the Pace was dropped, - the rest of the 1st para was dropped down into 6.1 - there was some weasel wording about RFC3023 compliance how would you feel about the rest of it? For example, [[[ N Processing Atom markup N.1 Determining the character encoding of an Atom feed The concept of XML well-formedness relies on first determining the character encoding of the XML document. The rules for determining the character encoding of an Atom feed served over HTTP are no different to determining the character encoding of any XML document served over HTTP. Those rules are defined by RFC 3023 and are considered normative by this specification. They are summarized here as there has been confusion over how RFC 3023 should be interpreted. In order to comply with RFC 3023: 1. When serving an Atom feed, it is RECOMMENDED that publishers include the charset parameter along with the media type in the Content-type HTTP header. If the charset parameter is present, clients MUST parse the Atom feed in that charset, ignoring any charset declared in the encoding attribute of the XML declaration. 1. Publishers SHOULD serve Atom feeds with the media type "application/atom+xml" (registered in Section @@@ of this document). 1. If a publisher wishes to serve an Atom feed over HTTP, but for some reason they are unable to use the "application/atom+xml" media type, the publisher SHOULD use "application/xml". 1. Clients MUST determine the character encoding as per RFC 3023 or its successor. 1. If a publisher is unable to serve their Atom feed with a Content-Type of "application/atom+xml" or "application/xml", they MAY use "text/xml". Note: according to RFC 3023, XML documents served as "text/xml" with no charset parameter have a character encoding of "us-ascii". 1. When serving an Atom feed as "text/xml", publishers MUST escape all non-US-ASCII characters as [http://www.w3.org/TR/REC-xml/#sec-references character references] to comply with RFC 3023. For example, 'ø' for the character 'ø'. 1. When retrieving an Atom feed served with a Content-type of "text/xml": 1. clients MUST parse it with a "us-ascii" encoding in order . 1. if such a feed contains non-US-ASCII characters, and clients MUST reject it as non-well-formed. 1. Publishers MUST NOT serve Atom feeds with a media type other than the XML media types defined in RFC 3023 or its successor. In particular Atom publishers are expected to note that "text/plain" is not an appropriate media type for an Atom feed. 1. When retrieving an Atom feed served with a non-XML media type,, clients MUST reject it as non-well-formed. ]]] While I think we have to be realistic about people do with markup in the wild, I find nothing above controversial or overconstraining in the above from a specification viewpoint. It's being worded in such a way that implementors can make a decision to comply with RFC 3023 or not. After a time, we'll be able to see whether or not RFC 3023 is actually useful, but right now, I don't see how we can punt on this matter. cheers Bill From owner-atom-syntax@mail.imc.org Thu Feb 3 05:46:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08912 for ; Thu, 3 Feb 2005 05:46:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13Abg17043303; Thu, 3 Feb 2005 02:37:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13AbgaE043301; Thu, 3 Feb 2005 02:37:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13AbfAA043293 for ; Thu, 3 Feb 2005 02:37:41 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 22657 invoked by uid 17064); 3 Feb 2005 10:37:41 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.10.189]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 3 Feb 2005 10:37:41 -0000 In-Reply-To: <9831AF60-748C-11D9-9FA4-003065EA6144@geckotribe.com> References: <9831AF60-748C-11D9-9FA4-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2cd81e77542cf2c35a0a51e386efa941@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: Principled Reasoning. was: PaceAggregationDocument posted Date: Thu, 3 Feb 2005 11:37:15 +0100 To: Antone Roundy , Robert Sayre , Jeremy Gray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks these are much more helpful in working out the Principles/requirements that guide your thinking. Here are two requirements that make sense to me and seem close to giving the same results in preferences that you have: P1. Atom documents should be easily parsable. P2. Atom documents should be easily updatable. I think P2 is especially difficult for a format that would be recursive such as feed entry1 entry2 entry response1 entry response1.1 entry response2 as it might force updates to add xml to the middle of an xml document and so force the whole document to be regenerated. Placing entries in a sequence and having them refer to each other by reference makes it much easier to update your original document. In RDF this would be similar to the TRiX or the RPV (presented by Tim Bray) proposals [1]. And this comparison may lead us to see perhaps how to find an agreement with the intuitions behind the paceFeedRecursive or "Entry is a subclass of Feed" type proposals. Those proposals are put forward from the point of view of: P3. Simple is beautiful But perhaps the simplicity that is searched for there is a simplicity in the model. Indeed from a programmatic point of view nothings is quite as beautiful as a nice recursive algorithm. But perhaps we can have both points of views live happily together, and perhaps the rdf experience points out how to do this: by separating the syntax from the model. Let us imagine we have a nice and simple model where for example a Feed is a subclass of an Entry. We could present this model very precisely in an OWL ontology in a recursive way. But we could then limit the ways to write out this model with a Relax NG schema. Atom would then have 1. a simple model and 2. a simple syntax. Perfection would then be had by making absolutely clear that the model is a model of the syntax allowed by the relaxng compliant document, by making sure the relaxng compliant document also be a rdf/xml document. Henry Story http://bblfish.net/ [1] http://www.fakeroot.net/sw/rdf-formats-20040717/#rpv On 1 Feb 2005, at 21:05, Antone Roundy wrote: > On Tuesday, February 1, 2005, at 06:08 AM, Henry Story wrote: > ... > Without taking the trouble to purchase and read the book you pointed > to, here is my reasoning: > >>> Antone Roundy wrote: >>> >>>> My preferences: >>>> >>>> +1: Current draft or PaceAggregationDocument (with or without >>>> atom:feed/atom:head and with or without metadata for >>>> atom:aggregation (atom:aggregation/atom:head?)) > Stable paths to the elements of a feed. Greatest > simplicity--certainly the way that I implement my code, these are the > simplest. > >>>> +0.5: PaceFeedRecursive without any more indirection than we >>>> already have, and only one level of recursion > Less stable paths to elements since you don't know in advance whether > the entries will be in the outermost feed, or whether some or all of > them will be inside another feed layer. > >>>> -0.8: Real RDF > I think we've discussed this one enough--RDF adds overhead that I > don't value. Others do. I don't. > >>>> -1: PaceFeedRecursive as it stands (no extra indirection, but >>>> unlimited levels of recursion) > I don't want to have to deal with the added complexity of potentially > unlimited recursion, nor do I see value in allowing it. Sure, it can > show you the long list of feeds that an entry traversed to get from > its original feed to the current feed, but for those who value that > more than I do, there MUST be a better way to do it. > >>>> -1.5: "add an attribute to atom:entry that indicates whether it >>>> refers to an instance of entry or another feed" > I'm not entirely sure what is intended by this, but it sounds like a > combination of unlimited recursion and not even knowing whether and > entry is an entry or a feed without examining it's attributes. I > assume this is basically "a feed is an entry, so let's use the same > element for both"? > >>>> -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 that don't hand of HTML content to some widget for > handling, and thus have to handle the details of loading images and > such themselves, but for applications that do, it's much simpler to be > able to get everything that they need to manipulate with one request > and be done with it. We already have indirection for , which > I personally would be happier without. I'd like to avoid adding more. > From owner-atom-syntax@mail.imc.org Thu Feb 3 05:54:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09345 for ; Thu, 3 Feb 2005 05:54:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13AkLJL046042; Thu, 3 Feb 2005 02:46:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13AkLJJ046041; Thu, 3 Feb 2005 02:46:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.192]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13AkKvp046006 for ; Thu, 3 Feb 2005 02:46:20 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 34so152308rns for ; Thu, 03 Feb 2005 02:46:15 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=n0AcJvUITmgj9rAIX4aIkDFR+uVJFij1RUSPPYFt71jYY9Zwi2L039p8nauCGQ9MqTMd0aaavGeSJUyEATV2CDaTNBL30Gn2BTJN1nZR66RuctiP+tdTVKecM/x61EJWxfCioGi2P6em6vYNDX2FDkgclrfNxw/oo72R1UfSGYY= Received: by 10.38.206.45 with SMTP id d45mr498257rng; Thu, 03 Feb 2005 02:46:14 -0800 (PST) Received: by 10.38.179.46 with HTTP; Thu, 3 Feb 2005 02:46:14 -0800 (PST) Message-ID: <1f2ed5cd050203024648b8b1fa@mail.gmail.com> Date: Thu, 3 Feb 2005 11:46:14 +0100 From: Danny Ayers Reply-To: Danny Ayers To: Sam Ruby Subject: Re: Thinking ahead: Atom Extension Proposals on the Wiki? Cc: James Snell , Tim Bray , Atom Syntax In-Reply-To: <42017E00.5000900@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c40502021158637bb7ed@mail.gmail.com> <2bcdc7c405020215216b192094@mail.gmail.com> <42017E00.5000900@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby wrote: > > 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 finalized? > Go4it. Yep, good idea. I can see a few in the intray: ipaddress/host (for anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension is in the process of being revised, and an Atom-compatible syntax is planned; Yahoo's media object extension. A Wiki template would be nice - have you started writing anything up yet, James? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Thu Feb 3 06:41:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12884 for ; Thu, 3 Feb 2005 06:41:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13BW9Tr061843; Thu, 3 Feb 2005 03:32:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13BW99e061842; Thu, 3 Feb 2005 03:32:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13BW8SR061695 for ; Thu, 3 Feb 2005 03:32:08 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:49471 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228728AbVBCLbt (ORCPT ); Thu, 3 Feb 2005 13:31:49 +0200 In-Reply-To: <2bcdc7c4050202220947793133@mail.gmail.com> References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <2bcdc7c4050202220947793133@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4477c08ae9ca14eaa6b4732842a5c684@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Eric Scheid From: Henri Sivonen Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Date: Thu, 3 Feb 2005 13:31:45 +0200 To: James Snell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 3, 2005, at 08:09, James Snell wrote: > What is the model for archiving with Atom? What's the *point* in archiving with Atom compared to eg. a zip archive with some HTML or XHTML files in it (with relative links and a stipulation that index.html and index.xhtml are magic names)? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Feb 3 07:22:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15327 for ; Thu, 3 Feb 2005 07:22:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13CBPLQ075202; Thu, 3 Feb 2005 04:11:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13CBPHY075201; Thu, 3 Feb 2005 04:11:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j13CBNPC075160 for ; Thu, 3 Feb 2005 04:11:23 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 03 Feb 2005 12:11:17 -0000 Received: from p50824E32.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.78.50) by mail.gmx.net (mp024) with SMTP; 03 Feb 2005 13:11:17 +0100 X-Authenticated: #1915285 Message-ID: <420214E3.7020409@gmx.de> Date: Thu, 03 Feb 2005 13:11:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceMustBeWellFormed References: <4201B27C.6070003@franklinmint.fm> <4201F504.5030609@dehora.net> In-Reply-To: <4201F504.5030609@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > If, > > - 6.2 was dropped and probably > - the first sentence of the Pace was dropped, > - the rest of the 1st para was dropped down into 6.1 > - there was some weasel wording about RFC3023 compliance > > how would you feel about the rest of it? > ... I think the main issue here is first we say 1) ...SHOULD use application/atom+xml... ...then, if you don't want to... 2) ...SHOULD use application/xml... ...then finally... 3) otherwise MAY use text/xml. That is a problem in itself. Either we mandate a specific content type or we don't (I think we should). If we mandate one, we should say that behaviour of documents served with a different type is simply undefined. Note that most of the nasty RFC3023 problems only apply to text/*, in particular I don't see why we would want to RECOMMEND to use a charset parameter on application/* content types. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Thu Feb 3 10:40:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05674 for ; Thu, 3 Feb 2005 10:40:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13FK02T012650; Thu, 3 Feb 2005 07:20:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13FK0jC012649; Thu, 3 Feb 2005 07:20:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13FK0wb012633 for ; Thu, 3 Feb 2005 07:20:00 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020315195201200g675pe>; Thu, 3 Feb 2005 15:19:52 +0000 Date: Thu, 3 Feb 2005 08:19:50 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceCommentFeeds posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <0C4B8A53-75F7-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This doesn't seem to have made it when I sent it last night, so here it is again: An alternative to PaceEntriesElement - doesn't address all of the same issues, but combined with PaceAggregationDocument, would address a number of them. http://www.intertwingly.net/wiki/pie/PaceCommentFeeds Abstract Enable the creation of comment feeds (comments on an entry from another feed) and the atomization of other hierarchical data, such as discussion forums, without recursion, by adding "comments" to the lin/@rel registry, and allowing atom:content and atom:summary as children of atom:head. Status Open Rationale * Comments on weblog entries and comment feeds are a reality today. Atom does not currently have a good way to support them. * Other hierarchical data that is sometimes syndicated could use a good method of representation using Atom. * This method enables this while preserving the simplicity of a flat feed model. Proposal In section 4.2 of draft-ietf-atompub-format-05.txt, add the following to the lists of child elements of atom:head: & atomSummary? & atomContent? and: atom:head elements MUST NOT contain more than one atom:summary element. atom:head elements MUST NOT contain more than one atom:content element. Add the following to section 4.6.2: The value "comments" signifies that the URI in the value of the href attribute identifies a resource containing comments on the content of the containing atom:feed or atom:entry element. For example, the URI may identify another Atom feed document whose entries are comments about the containing atom:entry. From owner-atom-syntax@mail.imc.org Thu Feb 3 11:21:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11127 for ; Thu, 3 Feb 2005 11:21:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13G6XFB016253; Thu, 3 Feb 2005 08:06:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13G6X71016252; Thu, 3 Feb 2005 08:06:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13G6Sc1016234 for ; Thu, 3 Feb 2005 08:06:28 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so160978rne for ; Thu, 03 Feb 2005 08:06:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mU4n39gcczNOc1SWomnDH4UTI4/VALabA4uGymlrUJZ79D4GF2qbvQMjmUKU+LvCDyoq0z1mvbf3Z2pRgO3CQdG3vzKB04o9r2I7WApPW1gFLRKnDG0wHTw1X4nx0wq2A4aTECD70HVOUTYApFPkGmtE8Kk6zB45rkwflZosQWQ= Received: by 10.38.71.29 with SMTP id t29mr140237rna; Thu, 03 Feb 2005 08:06:22 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 08:06:22 -0800 (PST) Message-ID: <2bcdc7c4050203080649fca771@mail.gmail.com> Date: Thu, 3 Feb 2005 08:06:22 -0800 From: James Snell Reply-To: James Snell To: Danny Ayers Subject: Re: Thinking ahead: Atom Extension Proposals on the Wiki? Cc: Sam Ruby , Tim Bray , Atom Syntax In-Reply-To: <1f2ed5cd050203024648b8b1fa@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c40502021158637bb7ed@mail.gmail.com> <2bcdc7c405020215216b192094@mail.gmail.com> <42017E00.5000900@intertwingly.net> <1f2ed5cd050203024648b8b1fa@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I will start working on the template this week and will get something posted by the weekend. On Thu, 3 Feb 2005 11:46:14 +0100, Danny Ayers wrote: > On Wed, 02 Feb 2005 20:27:28 -0500, Sam Ruby wrote: > > > > 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 finalized? > > > Go4it. > > Yep, good idea. I can see a few in the intray: ipaddress/host (for > anon posts to Wikis etc); the ENT (Easy News Topics) RSS 2.0 extension > is in the process of being revised, and an Atom-compatible syntax is > planned; Yahoo's media object extension. > > A Wiki template would be nice - have you started writing anything up yet, James? > > Cheers, > Danny. > > > -- > > http://dannyayers.com > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 11:22:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11288 for ; Thu, 3 Feb 2005 11:22:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13GCCMb016677; Thu, 3 Feb 2005 08:12:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13GCCtj016676; Thu, 3 Feb 2005 08:12:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13GCB4A016668 for ; Thu, 3 Feb 2005 08:12:11 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <2005020316120601400397aae>; Thu, 3 Feb 2005 16:12:06 +0000 Date: Thu, 3 Feb 2005 09:12:04 -0700 Subject: Re: PaceCollection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <2bcdc7c4050202225559e7bc57@mail.gmail.com> Message-Id: <586C6C5E-75FE-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, February 2, 2005, at 11:55 PM, James Snell wrote: > In any case, we're talking about something as simple as the name of a > single element. I just don't see any real technical value in changing > it's name. It doesn't make processing any easier. It doesn't change > any of the functional semantics. It doesn't address any critical bugs > in the design. It just doesn't do anything. > Allow me to exaggerate. Had we been using the following names, there would obviously be a point in changing them: This is my blog 2004-01-25T10:04:00+0000 Johhny learns to read 2004-01-25T10:04:00+0000 [...] I resolve to blog 2004-01-24T14:02:00+0000 [...] Is "collection" more descriptive than "feed" of what we're using it for? Would it make for quicker absorbtion of the concept by people not already familiar with the term "feed"? Would it confuse those already familiar with the term "feed"? My only objection to "collection" is that it has two more syllables than "feed". From owner-atom-syntax@mail.imc.org Thu Feb 3 12:57:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20575 for ; Thu, 3 Feb 2005 12:57:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HjIiC035093; Thu, 3 Feb 2005 09:45:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13HjILX035092; Thu, 3 Feb 2005 09:45:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HjG8T035079 for ; Thu, 3 Feb 2005 09:45:16 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cwl2T-00065N-S5; Thu, 03 Feb 2005 17:45:10 +0000 Message-ID: <42026325.4000809@franklinmint.fm> Date: Thu, 03 Feb 2005 12:45:09 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: sub feeds (was Re: Call for final Paces for consideration: deadline imminent) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 3/2/05 7:18 PM, "Robert Sayre" wrote: > > no, feeds are collections, entries describe resources, and while feeds are > also resources that only means that entries can describe feeds, not actually > be feeds. I'm sorry, the whole point of my pace is that collections are resources. This is obviosly true. You just have to look at the flurry of Paces that resulted with hacky link relations to see that it's true. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 12:59:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20756 for ; Thu, 3 Feb 2005 12:59:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HnfWF035345; Thu, 3 Feb 2005 09:49:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13HnfZb035344; Thu, 3 Feb 2005 09:49:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HneL5035333 for ; Thu, 3 Feb 2005 09:49:41 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so196151rne for ; Thu, 03 Feb 2005 09:49:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=G9hgZmZfbkotHPGLCSb0abaRnIhhXK8QO1WsYZyxXoIK8nvqevACfUPRJJrbc10/RHc63gCzs0CBeb99V/D9ODAcGyeaV/uiKlsCKgMQKbM0n3eftNeOHY4LCVjlZf30ScfBtsm2tAzmg9850uRKaVw411Dvyx0VlGoDLqxtt5s= Received: by 10.38.151.22 with SMTP id y22mr126492rnd; Thu, 03 Feb 2005 09:49:35 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 09:49:35 -0800 (PST) Message-ID: <2bcdc7c405020309496ed30008@mail.gmail.com> Date: Thu, 3 Feb 2005 09:49:35 -0800 From: James Snell Reply-To: James Snell To: Antone Roundy Subject: Re: PaceCollection Cc: atom-syntax@imc.org In-Reply-To: <586C6C5E-75FE-11D9-8EFA-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c4050202225559e7bc57@mail.gmail.com> <586C6C5E-75FE-11D9-8EFA-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 09:12:04 -0700, Antone Roundy wrote: > > On Wednesday, February 2, 2005, at 11:55 PM, James Snell wrote: > > In any case, we're talking about something as simple as the name of a > > single element. I just don't see any real technical value in changing > > it's name. It doesn't make processing any easier. It doesn't change > > any of the functional semantics. It doesn't address any critical bugs > > in the design. It just doesn't do anything. > > > Allow me to exaggerate. Had we been using the following names, there > would obviously be a point in changing them: > You wouldn't need to change them if "guacamole" had a well-known, well-understood meaning in relation to what the XML syntax was trying to accomplish. The term "feed" has a well-known, well-understood meaning. > > > This is my blog > 2004-01-25T10:04:00+0000 > > > Johhny learns to read > 2004-01-25T10:04:00+0000 > [...] > > > I resolve to blog > 2004-01-24T14:02:00+0000 > [...] > > > > Is "collection" more descriptive than "feed" of what we're using it > for? Would it make for quicker absorbtion of the concept by people not > already familiar with the term "feed"? Would it confuse those already > familiar with the term "feed"? > I say yes to all of these. > My only objection to "collection" is that it has two more syllables > than "feed". > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Thu Feb 3 13:07:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21652 for ; Thu, 3 Feb 2005 13:07:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HtklW035688; Thu, 3 Feb 2005 09:55:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13HtkJX035687; Thu, 3 Feb 2005 09:55:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13HtjUM035681 for ; Thu, 3 Feb 2005 09:55:45 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwlCg-0006Dr-FU; Thu, 03 Feb 2005 17:55:42 +0000 Message-ID: <4202659E.3030000@franklinmint.fm> Date: Thu, 03 Feb 2005 12:55:42 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom-Syntax Subject: Re: PaceEntriesElement References: <42016CAA.2000000@franklinmint.fm> <4201ED3C.9000205@dehora.net> In-Reply-To: <4201ED3C.9000205@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > >> 2. Multiple feeds can be aggregated and presented using a single data >> format without having to modify the entries within those feeds to >> incorporate their original feed metadata; > > > That sounds like a win. > > >> 3. Digital signatures can be safely applied to feeds and entries >> without needing special-case exceptions on how to recreate the >> signature after aggregation; > > > Ultimately I'll defer to an expert on this, but I'd like to see an > example of a special case that is circumvented ;) > I'm not an expert, but I have produced signed feeds. It's easy to write what's known as a "collectable" signature, which allows its parent element to appear anywhere in the document. > >> 6. Practically zero changes for format05 feeds in the simple case. >> Entry elements are wrapped with atom:entries instead of headers being >> wrapped with atom:head. > > > Why not make make atom:head an atom:entry? > It does. It still groups the "headers". It's just implicit. > >> 7. Differentiates elements lower in a hierarchy (collection members) >> from metadata. > > > See my comment on 1. I think it only differentiates when we say it does, > and this already suggests two containment 'semantics' (ie, there'll be > an if/else in the code). Btw, this sounds like it's going to work like > RDF/XML striping. Yes, I wrote the initial feed in the RDF validator. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 13:29:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23733 for ; Thu, 3 Feb 2005 13:29:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13IK66N037358; Thu, 3 Feb 2005 10:20:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13IK60S037357; Thu, 3 Feb 2005 10:20:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13IK6uK037346 for ; Thu, 3 Feb 2005 10:20:06 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020318195901300k7b5se>; Thu, 3 Feb 2005 18:19:59 +0000 Date: Thu, 3 Feb 2005 11:19:58 -0700 Subject: Re: PaceCollection Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <2bcdc7c405020309496ed30008@mail.gmail.com> Message-Id: <3604F8E2-7610-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 10:49 AM, James Snell wrote: >> Allow me to exaggerate. Had we been using the following names, there >> would obviously be a point in changing them: > > You wouldn't need to change them if "guacamole" had a well-known, > well-understood meaning in relation to what the XML syntax was trying > to accomplish. The term "feed" has a well-known, well-understood > meaning. > >> ... >> Is "collection" more descriptive than "feed" of what we're using it >> for? Would it make for quicker absorbtion of the concept by people >> not >> already familiar with the term "feed"? Would it confuse those already >> familiar with the term "feed"? >> > I say yes to all of these. > I agree. The question whether the impact of the first two or the impact of the last is greater. I suspect that many of the people already familiar with the term "feed" would very quickly realize that "collection" is what used to be called "feed" (which is what used to be called "rss" in past lives)--much more quickly than people just getting into syndication (which, BTW, I don't think is that great a term, but that's another story) would be able to wrap their minds around "feed" as opposed to "collection". That said, I don't feel strongly about this, so I'll quit here. From owner-atom-syntax@mail.imc.org Thu Feb 3 13:29:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23757 for ; Thu, 3 Feb 2005 13:29:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13IKs7C037397; Thu, 3 Feb 2005 10:20:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13IKsdn037396; Thu, 3 Feb 2005 10:20:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13IKr1k037386 for ; Thu, 3 Feb 2005 10:20:53 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id EF30C13A; Thu, 3 Feb 2005 10:20:46 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j13IKbLf011613; Thu, 3 Feb 2005 10:20:42 -0800 (PST) Date: Thu, 03 Feb 2005 10:20:39 -0800 From: Walter Underwood To: Atom Syntax Cc: Henri Sivonen Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Message-ID: <3A139879CE16D1351AB68693@Wunders-Computer.local> In-Reply-To: <4477c08ae9ca14eaa6b4732842a5c684@iki.fi> References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <2bcdc7c4050202220947793133@mail.gmail.com> <4477c08ae9ca14eaa6b4732842a5c684@iki.fi> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 3, 2005 1:31:45 PM +0200 Henri Sivonen wrote: > On Feb 3, 2005, at 08:09, James Snell wrote: > >> What is the model for archiving with Atom? > > What's the *point* in archiving with Atom compared to eg. a zip archive with > some HTML or XHTML files in it (with relative links and a stipulation that > index.html and index.xhtml are magic names)? Cross-platform dump and load. Saving data that is in the database and not in the HTML. Backups. Dump and reload for an upgrade with a DB schema change. Consistent save from a live database (hold a read lock while you dump the archive). Insurance against your blog service going away on short notice. Sarbanes-Oxley compliance for corporate blogs (internal and external). And of course, so Brewster Kahle can keep a copy. The Wayback Machine has saved my butt a couple of times. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Thu Feb 3 15:30:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05423 for ; Thu, 3 Feb 2005 15:30:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KEEtc046236; Thu, 3 Feb 2005 12:14:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13KEE0E046235; Thu, 3 Feb 2005 12:14:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KECSJ046214 for ; Thu, 3 Feb 2005 12:14:13 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:49959 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228754AbVBCUN6 (ORCPT ); Thu, 3 Feb 2005 22:13:58 +0200 In-Reply-To: <3A139879CE16D1351AB68693@Wunders-Computer.local> References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <2bcdc7c4050202220947793133@mail.gmail.com> <4477c08ae9ca14eaa6b4732842a5c684@iki.fi> <3A139879CE16D1351AB68693@Wunders-Computer.local> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1e63fe3bc5be46451915faa8b702ebb1@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Date: Thu, 3 Feb 2005 22:13:56 +0200 To: Walter Underwood X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 3, 2005, at 20:20, Walter Underwood wrote: > --On February 3, 2005 1:31:45 PM +0200 Henri Sivonen > wrote: >> What's the *point* in archiving with Atom compared to eg. a zip >> archive with >> some HTML or XHTML files in it (with relative links and a stipulation >> that >> index.html and index.xhtml are magic names)? > > Cross-platform dump and load. Saving data that is in the database and > not > in the HTML. Why couldn't you dump from a database to an (X)HTML entry in a zip archive if you can dump into a 'content' element in an Atom file? > Backups. Dump and reload for an upgrade with a DB schema change. > Consistent save from a live database (hold a read lock while you dump > the > archive). Insurance against your blog service going away on short > notice. > Sarbanes-Oxley compliance for corporate blogs (internal and external). What value does Atom as yet another container format add over .zip (perhaps with a metadata manifest as in .jar) or .mht? Why would anyone, who so far has not implemented zip/mht dump and load, implement Atom dump and load? (Compared to all competing Base64-in-text-or-XML aggregate document formats, zip-based OOo files are surprisingly elegant.) -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Thu Feb 3 15:47:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07224 for ; Thu, 3 Feb 2005 15:47:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KcZ5t048769; Thu, 3 Feb 2005 12:38:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13KcZq3048768; Thu, 3 Feb 2005 12:38:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KcY26048756 for ; Thu, 3 Feb 2005 12:38:34 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020320382401100ckij8e>; Thu, 3 Feb 2005 20:38:24 +0000 Date: Thu, 3 Feb 2005 13:38:22 -0700 Subject: Re: Atom for Archives (was:Re: Call for final Paces for consideration: deadline imminent) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <1e63fe3bc5be46451915faa8b702ebb1@iki.fi> Message-Id: <8BDBC292-7623-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 01:13 PM, Henri Sivonen wrote: > On Feb 3, 2005, at 20:20, Walter Underwood wrote: >> --On February 3, 2005 1:31:45 PM +0200 Henri Sivonen >> wrote: >> Backups. Dump and reload for an upgrade with a DB schema change. >> Consistent save from a live database (hold a read lock while you dump >> the >> archive). Insurance against your blog service going away on short >> notice. >> Sarbanes-Oxley compliance for corporate blogs (internal and external). > > What value does Atom as yet another container format add over .zip > (perhaps with a metadata manifest as in .jar) or .mht? It's readable by feed readers. I think we're not all talking about the same meaning of the word "archive". We aren't talking about what you do when you compress a bunch of files into a zip, tgz, sit...file. We're not talking about Base64ing all your photos so that you can stuff them into a single Atom document for backup. Unless I'm mistaken, we're talking essentially about using (relatively) static Atom documents to store the portions of a stream of entries (aka a "feed") that have passed through the "sliding window". From owner-atom-syntax@mail.imc.org Thu Feb 3 16:05:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08980 for ; Thu, 3 Feb 2005 16:05:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KwNra050246; Thu, 3 Feb 2005 12:58:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13KwNTS050245; Thu, 3 Feb 2005 12:58:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KwMEo050236 for ; Thu, 3 Feb 2005 12:58:22 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13KwJVu008389 for ; Thu, 3 Feb 2005 13:58:19 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00L01STPCH@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 15:58:19 -0500 (EST) Received: from localhost (vpn-129-150-33-149.Central.Sun.COM [129.150.33.149]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC00FIXSWXPE@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 15:58:19 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cwo2u-0000iL-8R for atom-syntax@imc.org; Thu, 03 Feb 2005 15:57:48 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 15:57:45 -0500 From: Norman Walsh Subject: Re: PaceEnclosuresAndPix status In-reply-to: To: Atom Syntax Message-id: <87pszh8ipi.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> <308D49DC-6FFF-11D9-9153-000A95DC3D90@mac.com> <653B7DE8-7006-11D9-BA76-000A95CA7396@ranchero.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Tim Bray was heard to say: | On Jan 26, 2005, at 7:16 PM, Graham wrote: | |> Can you outline the problem[s] that having a icon link tag in the |> feed might cause? HTML already has a meta tag for it, so it seems |> like a simple feature-parity issue. | | Well, I don't think we're after feature-parity with HTML :) | | Seriously, the existing "HTML feature" by which we mean conventional | web-browser feature, works by fetching /favicon.ico; so Atom client I thought modern browsers followed the "icon" link: (in preference to, if not instead of, attempting the grotesque hack of grabbing /favicon.ico) Be seeing you, norm =2D-=20 Norman Walsh | You must not think me necessarily http://nwalsh.com/ | foolish because I am facetious, nor | will I consider you necessarily wise | because you are grave.--Sydney Smith --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApBLOyltUcwYWjsRAjeEAKCg2nC6p99RXWo+cToCxm+0p4iiXwCfZvob DlFwCoh24yg/qrD59RCardY= =yQsl -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:15:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10870 for ; Thu, 3 Feb 2005 16:15:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L3GZI050774; Thu, 3 Feb 2005 13:03:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13L3GEO050773; Thu, 3 Feb 2005 13:03:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L3EhT050736 for ; Thu, 3 Feb 2005 13:03:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 10:02:48 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 08:01:58 +1100 Subject: Re: PaceCollection From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c405020309496ed30008@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 4:49 AM, "James Snell" wrote: > You wouldn't need to change them if "guacamole" had a well-known, > well-understood meaning in relation to what the XML syntax was trying > to accomplish. The term "feed" has a well-known, well-understood > meaning. Fruit & veg departments in grocery stores are named "fruit & veg". Very few of them are named "potatoes and bananas", even though "potatoes" and "bananas" are words with well-known and well-understood meaning. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 16:15:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10901 for ; Thu, 3 Feb 2005 16:15:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L82l7051066; Thu, 3 Feb 2005 13:08:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13L8213051065; Thu, 3 Feb 2005 13:08:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L81om051058 for ; Thu, 3 Feb 2005 13:08:01 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13L81Vu014619 for ; Thu, 3 Feb 2005 14:08:01 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00101T8T01@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 16:08:01 -0500 (EST) Received: from localhost (vpn-129-150-33-149.Central.Sun.COM [129.150.33.149]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC00FF6TD7PE@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 16:08:01 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1CwoCP-0000mf-3M for atom-syntax@imc.org; Thu, 03 Feb 2005 16:07:37 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 16:07:33 -0500 From: Norman Walsh Subject: Re: Trial format-05 atom feed In-reply-to: To: Atom Syntax Message-id: <87lla58i96.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <4200C7B3.8070900@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Tim Bray was heard to say: | 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. I've just this minute decided that instead of trying to comment on the -05 draft, about which I have seen a huge number of comments, I'll go off and work on the RNG, starting with the test collection Sam pointed me to last time I asked. Be seeing you, norm =2D-=20 Norman Walsh | In the life of saints, technically so http://nwalsh.com/ | called, the spiritual facilities are | strong, but what gives the impression | of extravagance proves usually on | examination to be a relative deficiency | of intellect.--William James --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApKYOyltUcwYWjsRAsD8AJ41XTIkuPMkNG3Atg+t1z04blyAbgCggOeL I6womiY5F+nPY0uUHTw26l8= =5ZI3 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:16:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11009 for ; Thu, 3 Feb 2005 16:15:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L8OFO051099; Thu, 3 Feb 2005 13:08:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13L8OAP051098; Thu, 3 Feb 2005 13:08:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13L8NiV051091 for ; Thu, 3 Feb 2005 13:08:23 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13L8NVu014858 for ; Thu, 3 Feb 2005 14:08:23 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00101T8T01@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 16:08:23 -0500 (EST) Received: from localhost (vpn-129-150-33-149.Central.Sun.COM [129.150.33.149]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC00FGWTDPPE@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 16:08:23 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1CwoCm-0000n1-AD for atom-syntax@imc.org; Thu, 03 Feb 2005 16:08:00 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 16:08:00 -0500 From: Norman Walsh Subject: Re: tagline -> subtitle In-reply-to: <71234c9ab7c316582d9da9c077b76457@mac.com> To: Atom Syntax Message-id: <87hdkt8i8f.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <71234c9ab7c316582d9da9c077b76457@mac.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Graham was heard to say: | Any chance of renaming atom:tagline to atom:subtitle? The two sample | feeds posted today have the taglines "ongoing fragmented essay by Tim | Bray" and "WebDAV related news". Aren't taglines meant to be funny or | catchy or clever? +1 Be seeing you, norm =2D-=20 Norman Walsh | Old age is the most unexpected of all http://nwalsh.com/ | the things that happen to a man.-- | Trotsky --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApKwOyltUcwYWjsRAjYXAJ9VIu9znsrNVtmFZ6gjc15xnn5RCgCeIWsE xKVuDC12LMWSb6qfcuqeGTE= =852o -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:18:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11506 for ; Thu, 3 Feb 2005 16:18:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LB05Y051274; Thu, 3 Feb 2005 13:11:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13LB0kw051273; Thu, 3 Feb 2005 13:11:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LAxGN051266 for ; Thu, 3 Feb 2005 13:11:00 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j13LAxdt029256 for ; Thu, 3 Feb 2005 14:10:59 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00201TFZ76@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 16:10:59 -0500 (EST) Received: from localhost (vpn-129-150-33-149.Central.Sun.COM [129.150.33.149]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC00FY7THZPE@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 16:10:59 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1CwoEy-0000pR-FX for atom-syntax@imc.org; Thu, 03 Feb 2005 16:10:16 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 16:10:11 -0500 From: Norman Walsh Subject: Re: RELAX-NG bug in draft-05? In-reply-to: <13710384749.20050202235117@djpowell.net> To: Atom Syntax Message-id: <87d5vh8i4s.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <13710384749.20050202235117@djpowell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable / David Powell was heard to say: | 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? More like a thinko. I probably just assumed that anyElement could appear in atom:feed. I'm surprised the spec forbids it, but I'll adjust the schema to reflect that if it's the consensus of the group. Be seeing you, norm =2D-=20 Norman Walsh | Man's great misfortune is that he has http://nwalsh.com/ | no organ, no kind of eyelid or brake, | to mask or block a thought, or all | thought, when he wants to.--Paul Val=C3=A9ry --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApM1OyltUcwYWjsRAnPOAJ4yvu6ix0K/D62DuvJD9otalNzXGACfdg+k Vub8nh2s5TBqRrhDzZOMMRM= =Ly4O -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:30:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14808 for ; Thu, 3 Feb 2005 16:30:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LJ4lU051964; Thu, 3 Feb 2005 13:19:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13LJ4HJ051963; Thu, 3 Feb 2005 13:19:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LJ3Iu051957 for ; Thu, 3 Feb 2005 13:19:03 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13LJ3Vw021522 for ; Thu, 3 Feb 2005 14:19:03 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00301TOAJ1@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 16:19:03 -0500 (EST) Received: from localhost (vpn-129-150-33-149.Central.Sun.COM [129.150.33.149]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC00FCFTVOPE@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 16:19:03 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1CwoNA-0000uS-9I for atom-syntax@imc.org; Thu, 03 Feb 2005 16:18:44 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 16:18:44 -0500 From: Norman Walsh Subject: PaceRemoveVersionAttr To: Atom Syntax Message-id: <878y658hqj.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Some thoughts =2D It seems very likely to me that Atom will evolve over time. =2D For some applications, changing the namespace name with every version is entirely impractical. Atom may or may not be in this category. Do feeds become legacy? Are people storing entries with the expectation that the readers of 2014 will be able to display them, albeit perhaps imperfectly? Changing the namespace makes that *hard*. XSLT transformations and XML Queries for Namespace1 flatly will not work with Namespace2. =2D When I look at a feed, I am comforted on some emotional level by my ability to know what version the creator intended it to be. =2D Perhaps YAGNI applies. I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down in the road over it. Be seeing you, norm =2D-=20 Norman Walsh | Life is a great bundle of little http://nwalsh.com/ | things.--Oliver Wendell Holmes --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApU0OyltUcwYWjsRAtncAJ48Bx7iNPT9ego4gYvqB+2Tpsb6QQCgrl7d oVIa7E6lMiQ5rYgCTTShrB8= =gH+M -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:46:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18136 for ; Thu, 3 Feb 2005 16:46:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13Lbnsr053619; Thu, 3 Feb 2005 13:37:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13LbnF4053618; Thu, 3 Feb 2005 13:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13Lbmo3053578 for ; Thu, 3 Feb 2005 13:37:49 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j13LaCGq028083; Thu, 3 Feb 2005 21:36:22 GMT In-Reply-To: <878y658hqj.fsf@nwalsh.com> References: <878y658hqj.fsf@nwalsh.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-310353501; protocol="application/pkcs7-signature" Message-Id: <54e8033a44284de773d148639e13e44c@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceRemoveVersionAttr Date: Thu, 3 Feb 2005 21:36:11 +0000 To: Norman Walsh X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-2-310353501 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote: > I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down > in the road over it. Yes. I like it too. Graham --Apple-Mail-2-310353501 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjAzMjEzNjEyWjAjBgkqhkiG9w0BCQQxFgQUjkzCxlZdjh8tMHdys0Zw3K46 PeEweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAKapjPprGm0LNWAlG6j//scAL Bcmf0aYe2vgiAixR3Ik0OKww3YY1jQSGDTVappdgaUi3CI+6j9BGOAAcTjDzuSmi+Eojuinb84wB 3EeXnA+yyGSubO1GEoI71sEie3bL1SDRd4enDr6gFedO1yOjLgRAo+yIjsY9u26+zTM0Nap5ahhB r203Hkn/e1ZNcfl4wyTOtHUCmfc8x5NfptASuKinKEqzHLZkE9vcFox2mjKchnCb0MrsVxnk3oeS NxmMao3dpMN4ApdVHrNVLDpgSOLuMwKYCNXfMhGAO4ZtOGfcuSya4iuP0GSu5Znf/mJf5okJ8pEc k3YOKMNGO9DxAgAAAAAAAA== --Apple-Mail-2-310353501-- From owner-atom-syntax@mail.imc.org Thu Feb 3 16:58:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20900 for ; Thu, 3 Feb 2005 16:58:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LokcB055777; Thu, 3 Feb 2005 13:50:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13Lok9A055776; Thu, 3 Feb 2005 13:50:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf41.cluster1.charter.net (mxsf41.cluster1.charter.net [209.225.28.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13LojBB055764 for ; Thu, 3 Feb 2005 13:50:46 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip07.cluster1.charter.net (mxip07a.cluster1.charter.net [209.225.28.137]) by mxsf41.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j13LodUZ003149 for ; Thu, 3 Feb 2005 16:50:40 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip07.cluster1.charter.net with ESMTP; 03 Feb 2005 16:50:38 -0500 X-Ironport-AV: i="3.88,177,1102309200"; d="scan'208"; a="585149091:sNHT58044146" Received: from ndw by localhost with local (Exim 4.44) id 1Cworb-0001IA-O5 for atom-syntax@imc.org; Thu, 03 Feb 2005 16:50:11 -0500 To: Atom Syntax Subject: RELAX NG Grammar question From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 16:50:11 -0500 Message-ID: <87acql71po.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable There are some constraints that the RELAX NG grammar can't practically enforce. Should it enforce the MUSTs of the specification or the SHOULDs? For example, should it allow non-XHTML elements inside a Content Construct with the type 'XHTML'? Be seeing you, norm =2D-=20 Norman Walsh | If you are losing your leisure, look http://nwalsh.com/ | out! You may be losing your | soul.--Logan Pearsall Smith --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCApyTOyltUcwYWjsRAhY5AJ4xNfzkaCE5pXZo+ysKYIBg6wZDFgCfRjQU T6miMBhl80n7tvHbVeqN71w= =RTLm -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 17:13:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27016 for ; Thu, 3 Feb 2005 17:13:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13M3xge056841; Thu, 3 Feb 2005 14:03:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13M3xU7056840; Thu, 3 Feb 2005 14:03:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf32.cluster1.charter.net (mxsf32.cluster1.charter.net [209.225.28.156]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13M3xmE056830 for ; Thu, 3 Feb 2005 14:03:59 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip05.cluster1.charter.net (mxip05a.cluster1.charter.net [209.225.28.135]) by mxsf32.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j13M3rUW017853 for ; Thu, 3 Feb 2005 17:03:53 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip05.cluster1.charter.net with ESMTP; 03 Feb 2005 17:03:50 -0500 X-Ironport-AV: i="3.88,177,1102309200"; d="scan'208"; a="584009056:sNHT15474124" Received: from ndw by localhost with local (Exim 4.44) id 1Cwp4S-0001O4-PF for atom-syntax@imc.org; Thu, 03 Feb 2005 17:03:28 -0500 To: Atom Syntax Subject: Exactly one atom:contributor? From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 17:03:28 -0500 Message-ID: <87y8e55mj3.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable I find the constraint that an atom:feed or atom:entry can contain at most one atom:contributor a little odd. Suppose Tom, Dick, and Harry work on an entry, why can only two of them get credit (one as author and one as contributor). Why am I not allowed to indicate that they each contributed to the entry? For that matter, I wonder if the constraint makes sense for author. Kind of, sort of, maybe. Be seeing you, norm =2D-=20 Norman Walsh | The First Amendment is often http://nwalsh.com/ | inconvenient. But that is besides the | point. Inconvenience does not absolve | the government of its obligation to | tolerate speech.--Justice Anthony | Kennedy, in 91-155 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCAp+wOyltUcwYWjsRAkSMAJ4wxhshUqfKL79ZmNyR2iagdw7wNQCePpZB hocNgvvc+sXZ4eqNAGfcpmw= =/UQm -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 17:25:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28850 for ; Thu, 3 Feb 2005 17:25:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MBCD1057407; Thu, 3 Feb 2005 14:11:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MBBFk057406; Thu, 3 Feb 2005 14:11:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MBBBX057392 for ; Thu, 3 Feb 2005 14:11:11 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050203221105015009jb8qe>; Thu, 3 Feb 2005 22:11:05 +0000 Date: Thu, 3 Feb 2005 15:11:04 -0700 Subject: Re: PaceRemoveVersionAttr Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <878y658hqj.fsf@nwalsh.com> Message-Id: <7ED765BD-7630-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote: > - It seems very likely to me that Atom will evolve over time. > > - For some applications, changing the namespace name with every > version is entirely impractical. Atom may or may not be in this > category. Do feeds become legacy? Are people storing entries with > the expectation that the readers of 2014 will be able to display > them, albeit perhaps imperfectly? Changing the namespace makes that > *hard*. XSLT transformations and XML Queries for Namespace1 flatly > will not work with Namespace2. > > - When I look at a feed, I am comforted on some emotional level by my > ability to know what version the creator intended it to be. I used to be fairly attached to being able to see a version number in the feed, but no longer am, IF the following conditions are met. In the following, b > a and X != Y--the rest is indeterminate: 1) A valid Atom X.a feed is guaranteed to be a valid Atom X.b feed 2) An application aware of Atom X.a can safely ignore changes made in Atom X.b 3) The namespace for Atom version X.a is guaranteed to be the same as for Atom version X.b 4) The namespace for Atom version X.a is guaranteed to be different than the namespace for Atom version Y.c 5) X can easily be determined by viewing the namespace for Atom version X.* I think this is what we're aiming for, but I'm not certain that we have approved spec text to ensure it. PaceExtendingAtom addresses some of this, but not all of it. Do we need something more? From owner-atom-syntax@mail.imc.org Thu Feb 3 17:25:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28871 for ; Thu, 3 Feb 2005 17:25:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MB5dG057390; Thu, 3 Feb 2005 14:11:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MB5lx057389; Thu, 3 Feb 2005 14:11:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MB4XR057383 for ; Thu, 3 Feb 2005 14:11:04 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwpBk-0000D9-7f; Thu, 03 Feb 2005 22:11:00 +0000 Message-ID: <4202A173.3000601@franklinmint.fm> Date: Thu, 03 Feb 2005 17:10:59 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: Exactly one atom:contributor? References: <87y8e55mj3.fsf@nwalsh.com> In-Reply-To: <87y8e55mj3.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > I find the constraint that an atom:feed or atom:entry can contain at > most one atom:contributor a little odd. Suppose Tom, Dick, and Harry > work on an entry, why can only two of them get credit (one as author > and one as contributor). Why am I not allowed to indicate that they > each contributed to the entry? > > For that matter, I wonder if the constraint makes sense for author. > Kind of, sort of, maybe. That's a typo on my part. The Relax NG is correct. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 17:26:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28964 for ; Thu, 3 Feb 2005 17:26:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MGI4T057938; Thu, 3 Feb 2005 14:16:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MGHH2057936; Thu, 3 Feb 2005 14:16:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.sdf1.net (anakim.1meg.golden.net [216.75.172.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MGFGa057912 for ; Thu, 3 Feb 2005 14:16:16 -0800 (PST) (envelope-from kier@sdf1.net) Received: from [192.168.2.111] (HSE-Toronto-ppp315953.sympatico.ca [64.231.114.16]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by mail.sdf1.net (Postfix) with ESMTP id 1B8B8BCC7; Thu, 3 Feb 2005 17:16:08 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <54835bdaaf5de66ec560f1c43f479c29@sdf1.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , August Trometer From: Ray Slakinski Subject: Re: PaceLinkEnclosure needs help Date: Thu, 3 Feb 2005 17:15:56 -0500 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think your right in a way -- I agree that for 'alternate' it should be a child element, but I hate to do that for so lets drop that I said that. Having said that I still think rel would be good to keep. I want to keep it simple and as close to as possible. [-----] Ray Slakinski Fingerprint: C8AD 4847 2DA8 3469 079D 13F9 135D F0CF 1CFC FD03 Blog: http://ddll.sdf1.net Mosher's Law of Software Engineering: Don't worry if it doesn't work right. If everything did, you'd be out of a job. On 2-Feb-05, at 11:15 AM, Antone Roundy wrote: > > On Wednesday, February 2, 2005, at 05:09 AM, Ray Slakinski wrote: >> url, type, and length is pretty obvious, but rel could be used to >> specify alternate, torrent, quality and things like that, and allow >> future expansion without breaking when we do. >> > If the content being pointed to is an alternate of the entry content, > is probably better--using ) > for that would duplicate functionality. > > @rel probably isn't the best name for the other values you suggest. > Off the top of my head, I'd recommend allowing extension child > elements or extension attributes to specify such things. > From owner-atom-syntax@mail.imc.org Thu Feb 3 17:27:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29244 for ; Thu, 3 Feb 2005 17:27:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MH8sf058051; Thu, 3 Feb 2005 14:17:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MH8kh058050; Thu, 3 Feb 2005 14:17:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf19.cluster1.charter.net (mxsf19.cluster1.charter.net [209.225.28.219]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MH61b058038 for ; Thu, 3 Feb 2005 14:17:07 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip07.cluster1.charter.net (mxip07a.cluster1.charter.net [209.225.28.137]) by mxsf19.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j13MH06F010437 for ; Thu, 3 Feb 2005 17:17:00 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip07.cluster1.charter.net with ESMTP; 03 Feb 2005 17:16:59 -0500 X-Ironport-AV: i="3.88,177,1102309200"; d="scan'208"; a="585207326:sNHT15880522" Received: from ndw by localhost with local (Exim 4.44) id 1CwpHE-0001XF-78 for atom-syntax@imc.org; Thu, 03 Feb 2005 17:16:40 -0500 To: Atom Syntax Subject: atom:content in atom:entry From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 17:16:40 -0500 Message-ID: <87mzul5lx3.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Section 4.15 says: 4.15 The "atom:content" Element The "atom:content" element either contains or links to the content of the entry. atom:entry elements MUST contain zero or one atom:content elements. The constraint "atom:entry elements MUST contain zero or one atom:content elements." belongs in 4.3, I think. And is it still true? I can't tell if I'm allowed to have more than one if they have different types. What's the status quo? Be seeing you, norm =2D-=20 Norman Walsh | Everything we love, no doubt, will pass http://nwalsh.com/ | away, perhaps tomorrow, perhaps a | thousand years hence. Neither it nor | our love for it is any the less | valuable for that reason.--John Passmore --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCAqLIOyltUcwYWjsRAkZ0AJ4ijHiibhNQBSr+at3CencZnrXxiwCfQNFe kYcE90Sea70X6stcvXuLUsI= =Uj5x -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 17:38:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00463 for ; Thu, 3 Feb 2005 17:38:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MTQV2058841; Thu, 3 Feb 2005 14:29:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MTQs8058840; Thu, 3 Feb 2005 14:29:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MTQeH058834 for ; Thu, 3 Feb 2005 14:29:26 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwpTW-0000aO-CJ; Thu, 03 Feb 2005 22:29:22 +0000 Message-ID: <4202A5C1.6070604@franklinmint.fm> Date: Thu, 03 Feb 2005 17:29:21 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: atom:content in atom:entry References: <87mzul5lx3.fsf@nwalsh.com> In-Reply-To: <87mzul5lx3.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > Section 4.15 says: > > 4.15 The "atom:content" Element > > The "atom:content" element either contains or links to the content of > the entry. atom:entry elements MUST contain zero or one atom:content > elements. > > The constraint "atom:entry elements MUST contain zero or one atom:content > elements." belongs in 4.3, I think. > > And is it still true? I can't tell if I'm allowed to have more than one > if they have different types. What's the status quo? The status quo is that you cannot, it's still true, and the requirement is in the wrong place. The reason is that each atom:content element would require accessible alternative content, and result in reinvention of the feed structure. Also, no one uses them in Atom 0.3. Take a look at PaceEntriesElement as an alternative. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 17:46:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01615 for ; Thu, 3 Feb 2005 17:46:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MZw1r059559; Thu, 3 Feb 2005 14:35:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MZwti059558; Thu, 3 Feb 2005 14:35:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf36.cluster1.charter.net (mxsf36.cluster1.charter.net [209.225.28.161]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MZvGC059547 for ; Thu, 3 Feb 2005 14:35:57 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip04.cluster1.charter.net (mxip04a.cluster1.charter.net [209.225.28.134]) by mxsf36.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j13MZnpF012886 for ; Thu, 3 Feb 2005 17:35:49 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip04.cluster1.charter.net with ESMTP; 03 Feb 2005 17:35:48 -0500 X-Ironport-AV: i="3.88,177,1102309200"; d="scan'208?rnc'208"; a="616730751:sNHT29096064" Received: from ndw by localhost with local (Exim 4.44) id 1CwpZQ-0001lo-7v for atom-syntax@imc.org; Thu, 03 Feb 2005 17:35:28 -0500 To: Atom Syntax Subject: Updated Atom grammar From: Norman Walsh X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 17:35:18 -0500 Message-ID: <87is595l21.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="==-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain The test cases didn't turn out to be all that useful for my purpose, so I turned instead to another careful reading of the spec. Here is an updated grammar for Atom draft 0.5 modulo the constraint on contributor which is apparently a spec error rather than a grammar error :-) The changes are: * Fixed the namespace and version attribute * Allow anyElement in atom:person * Do not allow anyElement in atom:feed * Fixed the Schematron test for author in entry to reflect atom:head * Added Schematron rule to test for atom:content or atom:link[@rel=alternate] * Added Schematron rule to test for atom:summary or non-empty atom:content * Constrain atom:content to appearing at most once. --=-=-= Content-Type: application/octet-stream Content-Disposition: attachment; filename=atom.rnc Content-Transfer-Encoding: base64 IyAtKi0gUmVsYXggTkcgLSotCgpuYW1lc3BhY2UgbG9jYWwgPSAiIgpuYW1lc3BhY2UgYXRvbSA9 ICJodHRwOi8vcHVybC5vcmcvYXRvbS9ucyNkcmFmdC1pZXRmLWF0b21wdWItZm9ybWF0LTA1Igpu YW1lc3BhY2UgcyA9ICJodHRwOi8vd3d3LmFzY2MubmV0L3htbC9zY2hlbWF0cm9uIgoKc3RhcnQg PSBhdG9tRmVlZCB8IGF0b21FbnRyeQoKIyBBdHRyaWJ1dGUgZGVmaW5pdGlvbnMKCmF0b21Db21t b25BdHRyaWJ1dGVzID0KICAgYXR0cmlidXRlIHhtbDpiYXNlIHsgYXRvbVVyaSB9PywKICAgYXR0 cmlidXRlIHhtbDpsYW5nIHsgYXRvbUxhbmd1YWdlVGFnIH0/CgphdG9tVmVyc2lvbkF0dHJpYnV0 ZSA9CiAgIGF0dHJpYnV0ZSB2ZXJzaW9uIHsgImRyYWZ0LWlldGYtYXRvbXB1Yi1mb3JtYXQtMDUg OiBkbyBub3QgZGVwbG95IiB9CgojIENvbW1vbiBBdG9tIENvbnN0cnVjdHMKCmF0b21QbGFpblRl eHRDb25zdHJ1Y3QgPQogICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHR5cGUg eyAiVEVYVCIgfCAiSFRNTCIgfT8sCiAgIHRleHQKCmF0b21YSFRNTFRleHRDb25zdHJ1Y3QgPQog ICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHR5cGUgeyAiWEhUTUwiIH0sCiAg ICh0ZXh0fGFueUVsZW1lbnQpKgoKYXRvbVRleHRDb25zdHJ1Y3QgPSBhdG9tUGxhaW5UZXh0Q29u c3RydWN0IHwgYXRvbVhIVE1MVGV4dENvbnN0cnVjdAoKYXRvbVBlcnNvbkNvbnN0cnVjdCA9CiAg IGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAoZWxlbWVudCBhdG9tOm5hbWUgeyB0ZXh0IH0KICAg ICYgZWxlbWVudCBhdG9tOnVyaSB7IGF0b21VcmkgfT8KICAgICYgZWxlbWVudCBhdG9tOmVtYWls IHsgYXRvbUVtYWlsQWRkcmVzcyB9PwogICAgJiBhbnlFbGVtZW50KikKCmF0b21EYXRlQ29uc3Ry dWN0ID0KICAgYXRvbUNvbW1vbkF0dHJpYnV0ZXMsCiAgIHhzZDpkYXRlVGltZQoKYXRvbVNlcnZp Y2VDb25zdHJ1Y3QgPQogICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIG5hbWUg eyB0ZXh0IH0sCiAgIGF0dHJpYnV0ZSBocmVmIHsgYXRvbVVyaSB9CgphdG9tTGlua0NvbnN0cnVj dCA9CiAgIGF0b21Db21tb25BdHRyaWJ1dGVzLAogICBhdHRyaWJ1dGUgcmVsIHsgYXRvbU5DTmFt ZSB8IGF0b21VcmkgfT8sCiAgIGF0dHJpYnV0ZSB0eXBlIHsgYXRvbU1lZGlhVHlwZSB9PywKICAg YXR0cmlidXRlIGhyZWYgeyBhdG9tVXJpIH0sCiAgIGF0dHJpYnV0ZSBocmVmbGFuZyB7IGF0b21M YW5ndWFnZVRhZyB9PywKICAgYXR0cmlidXRlIHRpdGxlIHsgdGV4dCB9PywKICAgYXR0cmlidXRl IGxlbmd0aCB7IHRleHQgfT8sCiAgIGVtcHR5CgphdG9tSWRlbnRpdHlDb25zdHJ1Y3QgPQogICBh dG9tQ29tbW9uQXR0cmlidXRlcywKICAgKGF0b21VcmkpCgphdG9tQ2F0ZWdvcnlDb25zdHJ1Y3Qg PQogICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRlIHRlcm0geyB0ZXh0IH0sCiAg IGF0dHJpYnV0ZSBzY2hlbWUgeyBhdG9tVXJpIH0/LAogICBhdHRyaWJ1dGUgbGFiZWwgeyB0ZXh0 IH0/CgojIGF0b206ZmVlZAoKYXRvbUZlZWQgPQogICBlbGVtZW50IGF0b206ZmVlZCB7CiAgICAg IGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAgICBhdG9tVmVyc2lvbkF0dHJpYnV0ZSwKICAgICAg KGF0b21IZWFkCiAgICAgICAmIGF0b21FbnRyeSopCiAgIH0KCiMgYXRvbTpoZWFkCgphdG9tSGVh ZCA9CiAgIFsKICAgICAgczpydWxlIFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmhlYWQiCiAg ICAgICAgIHM6YXNzZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJhdG9tOmxpbmtbQHJlbD0nYWx0 ZXJuYXRlJ10iCiAgICAgICAgICAgICJBbiBhdG9tOmZlZWQgbXVzdCBoYXZlIGF0IGxlYXN0IG9u ZSBsaW5rIGVsZW1lbnQgd2l0aCBhIHJlbCBhdHRyaWJ1dGUgb2YgJ2FsdGVybmF0ZScuIgogICAg ICAgICBdCiAgICAgIF0KICAgICAgczpydWxlIFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmhl YWQiCiAgICAgICAgIHM6YXNzZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJhdG9tOmF1dGhvciBv ciBub3QoLi4vYXRvbTplbnRyeVtjb3VudChhdG9tOmF1dGhvcikgPSAwXSkiCiAgICAgICAgICAg ICJBbiBhdG9tOmZlZWQgbXVzdCBoYXZlIGFuIGF0b206YXV0aG9yIHVubGVzcyBhbGwgb2YgaXRz IGF0b206ZW50cnkgY2hpbGRyZW4gaGF2ZSBhbiBhdG9tOmF1dGhvci4iCiAgICAgICAgIF0KICAg ICAgXQogICBdCiAgIGVsZW1lbnQgYXRvbTpoZWFkIHsKICAgICAgYXRvbUNvbW1vbkF0dHJpYnV0 ZXMsCiAgICAgIChhdG9tVGl0bGUKICAgICAgICYgYXRvbUxpbmsrCiAgICAgICAmIGF0b21DYXRl Z29yeSoKICAgICAgICYgYXRvbUludHJvc3BlY3Rpb24/CiAgICAgICAmIGF0b21Qb3N0PwogICAg ICAgJiBhdG9tQXV0aG9yPwogICAgICAgJiBhdG9tQ29udHJpYnV0b3IqCiAgICAgICAmIGF0b21U YWdsaW5lPwogICAgICAgJiBhdG9tSWQ/CiAgICAgICAmIGF0b21HZW5lcmF0b3I/CiAgICAgICAm IGF0b21Db3B5cmlnaHQ/CiAgICAgICAmIGF0b21JbmZvPwogICAgICAgJiBhdG9tVXBkYXRlZAog ICAgICAgJiBhbnlFbGVtZW50KikKICAgfQoKIyBhdG9tOnRpdGxlCgphdG9tVGl0bGUgPSBlbGVt ZW50IGF0b206dGl0bGUgeyBhdG9tVGV4dENvbnN0cnVjdCB9CgojIGF0b206bGluawoKYXRvbUxp bmsgPSBlbGVtZW50IGF0b206bGluayB7IGF0b21MaW5rQ29uc3RydWN0IH0KCiMgYXRvbTpjYXRl Z29yeQoKYXRvbUNhdGVnb3J5ID0gZWxlbWVudCBhdG9tOmNhdGVnb3J5IHsgYXRvbUNhdGVnb3J5 Q29uc3RydWN0IH0KCiMgYXRvbTppbnRyb3NwZWN0aW9uCgphdG9tSW50cm9zcGVjdGlvbiA9IGVs ZW1lbnQgYXRvbTppbnRyb3NwZWN0aW9uIHsgYXRvbVNlcnZpY2VDb25zdHJ1Y3QgfQoKIyBhdG9t OnBvc3QKCmF0b21Qb3N0ID0gZWxlbWVudCBhdG9tOnBvc3QgeyBhdG9tU2VydmljZUNvbnN0cnVj dCB9CgojIGF0b206YXV0aG9yCgphdG9tQXV0aG9yID0gZWxlbWVudCBhdG9tOmF1dGhvciB7IGF0 b21QZXJzb25Db25zdHJ1Y3QgfQoKIyBhdG9tOmNvbnRyaWJ1dG9yCgphdG9tQ29udHJpYnV0b3Ig PSBlbGVtZW50IGF0b206Y29udHJpYnV0b3IgeyBhdG9tUGVyc29uQ29uc3RydWN0IH0KCiMgYXRv bTp0YWdsaW5lCgphdG9tVGFnbGluZSA9IGVsZW1lbnQgYXRvbTp0YWdsaW5lIHsgYXRvbVRleHRD b25zdHJ1Y3QgfQoKIyBhdG9tOmlkCgphdG9tSWQgPSBlbGVtZW50IGF0b206aWQgeyBhdG9tSWRl bnRpdHlDb25zdHJ1Y3QgfQoKIyBhdG9tOmdlbmVyYXRvcgoKYXRvbUdlbmVyYXRvciA9IGVsZW1l bnQgYXRvbTpnZW5lcmF0b3IgewogICBhdG9tQ29tbW9uQXR0cmlidXRlcywKICAgYXR0cmlidXRl IHVybCB7IGF0b21VcmkgfT8sCiAgIGF0dHJpYnV0ZSB2ZXJzaW9uIHsgdGV4dCB9PywKICAgdGV4 dAp9CgojIGF0b206Y29weXJpZ2h0CgphdG9tQ29weXJpZ2h0ID0gZWxlbWVudCBhdG9tOmNvcHly aWdodCB7IGF0b21UZXh0Q29uc3RydWN0IH0KCiMgYXRvbTppbmZvCgphdG9tSW5mbyA9IGVsZW1l bnQgYXRvbTppbmZvIHsgYXRvbVRleHRDb25zdHJ1Y3QgfQoKIyBhdG9tOm1vZGlmaWVkCiMgVE9E TzogVGVzdCBmb3IgYSB0aW1lem9uZSB0aGF0IFNIT1VMRCBiZSBVVEMKCmF0b21VcGRhdGVkID0g ZWxlbWVudCBhdG9tOnVwZGF0ZWQgeyBhdG9tRGF0ZUNvbnN0cnVjdCB9CgojIGF0b206ZW50cnkK IyBUT0RPOiBUZXN0IGZvciBtdWx0aXBsZSBhdG9tOmxpbmsgQHJlbD0nYWx0ZXJuYXRlJyB3aXRo IHRoZSBzYW1lIEB0eXBlCiMgVE9ETzogVGVzdCBmb3IgcmVxdWlyZWQgYXRvbTpzdW1tYXJ5Cgph dG9tRW50cnkgPQogICBbCiAgICAgIHM6cnVsZSBbCiAgICAgICAgIGNvbnRleHQgPSAiL2F0b206 ZW50cnkiCiAgICAgICAgIHM6YXNzZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJAdmVyc2lvbiIK ICAgICAgICAgICAgIlRoZSB2ZXJzaW9uIGF0dHJpYnV0ZSBpcyByZXF1aXJlZCBvbiBzdGFuZGFs b25lIGF0b206ZW50cnkgZWxlbWVudHMuIgogICAgICAgICBdCiAgICAgIF0KICAgICAgczpydWxl IFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmVudHJ5IgogICAgICAgICBzOmFzc2VydCBbCiAg ICAgICAgICAgIHRlc3QgPSAiYXRvbTpsaW5rW0ByZWw9J2FsdGVybmF0ZSddIgogICAgICAgICAg ICAiQW4gYXRvbTplbnRyeSBtdXN0IGhhdmUgYXQgbGVhc3Qgb25lIGxpbmsgZWxlbWVudCB3aXRo IGEgcmVsIGF0dHJpYnV0ZSBvZiAnYWx0ZXJuYXRlJy4iCiAgICAgICAgIF0KICAgICAgXQogICAg ICBzOnJ1bGUgWwogICAgICAgICBjb250ZXh0ID0gImF0b206ZW50cnkiCiAgICAgICAgIHM6YXNz ZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJhdG9tOmF1dGhvciBvciAuLi9hdG9tOmhlYWQvYXRv bTphdXRob3IiCiAgICAgICAgICAgICJBbiBhdG9tOmVudHJ5IG11c3QgaGF2ZSBhbiBhdG9tOmF1 dGhvciBpZiB0aGUgcGFyZW50IGF0b206ZmVlZCBkb2VzIG5vdC4iCiAgICAgICAgIF0KICAgICAg XQogICAgICBzOnJ1bGUgWwogICAgICAgICBjb250ZXh0ID0gImF0b206ZW50cnkiCiAgICAgICAg IHM6YXNzZXJ0IFsKICAgICAgICAgICAgdGVzdCA9ICJhdG9tOmNvbnRlbnQgb3IgYXRvbTpsaW5r W0ByZWw9J2FsdGVybmF0ZSddIgogICAgICAgICAgICAiQW4gYXRvbTplbnRyeSBtdXN0IGhhdmUg YW4gYXRvbTpjb250ZW50IG9yIGFuIGF0b206bGluayB3aXRoIGEgcmVsIGF0dHJpYnV0ZSBvZiAn YWx0ZXJuYXRlJy4iCiAgICAgICAgIF0KICAgICAgXQoKICAgICAgIyBOLkIuIFRoaXMgcnVsZSBk b2Vzbid0IHRlc3QgZm9yIGNvbnRlbnQgd2l0aCBhIG5vbi1iaW5hcnkgdHlwZS4KICAgICAgczpy dWxlIFsKICAgICAgICAgY29udGV4dCA9ICJhdG9tOmVudHJ5IgogICAgICAgICBzOmFzc2VydCBb CiAgICAgICAgICAgIHRlc3QgPSAiYXRvbTpzdW1tYXJ5IG9yIGF0b206Y29udGVudFtub3QoQHNy YyldIgogICAgICAgICAgICAiQW4gYXRvbTplbnRyeSBtdXN0IGhhdmUgYW4gYXRvbTpzdW1tYXJ5 IGlmIHRoZSBhdG9tOmNvbnRlbnQgZWxlbWVudCBpcyBlbXB0eS4iCiAgICAgICAgIF0KICAgICAg XQogICBdCiAgIGVsZW1lbnQgYXRvbTplbnRyeSB7CiAgICAgIGF0b21Db21tb25BdHRyaWJ1dGVz LAogICAgICBhdG9tVmVyc2lvbkF0dHJpYnV0ZT8sCiAgICAgIChhdG9tVGl0bGUKICAgICAgICYg YXRvbUxpbmsrCiAgICAgICAmIGF0b21DYXRlZ29yeSoKICAgICAgICYgYXRvbUVkaXQ/CiAgICAg ICAmIGF0b21BdXRob3I/CiAgICAgICAmIGF0b21Db250cmlidXRvcioKICAgICAgICYgYXRvbUhv c3Q/CiAgICAgICAmIGF0b21JZD8KICAgICAgICYgYXRvbVVwZGF0ZWQKICAgICAgICYgYXRvbVB1 Ymxpc2hlZD8KICAgICAgICYgYXRvbVN1bW1hcnk/CiAgICAgICAmIGF0b21Db250ZW50PwogICAg ICAgJiBhdG9tQ29weXJpZ2h0PwogICAgICAgJiBhdG9tSGVhZD8KICAgICAgICYgYW55RWxlbWVu dCopCiAgIH0KCiMgYXRvbTplZGl0CgphdG9tRWRpdCA9IGVsZW1lbnQgYXRvbTplZGl0IHsgYXRv bVNlcnZpY2VDb25zdHJ1Y3QgfQoKIyBhdG9tOmhvc3QKCiMgVE9ETzogdGlnaHRlbiB0aGlzIHVw CmF0b21Ib3N0ID0gZWxlbWVudCBhdG9tOmhvc3QgeyB0ZXh0IH0KCiMgYXRvbTpwdWJsaXNoZWQK CmF0b21QdWJsaXNoZWQgPSBlbGVtZW50IGF0b206cHVibGlzaGVkIHsgYXRvbURhdGVDb25zdHJ1 Y3QgfQoKIyBhdG9tOnN1bW1hcnkKCmF0b21TdW1tYXJ5ID0gZWxlbWVudCBhdG9tOnN1bW1hcnkg eyBhdG9tVGV4dENvbnN0cnVjdCB9CgojIGF0b206Y29udGVudAoKYXRvbUlubGluZVRleHRDb250 ZW50ID0KICAgZWxlbWVudCBhdG9tOmNvbnRlbnQgewogICAgICBhdG9tQ29tbW9uQXR0cmlidXRl cywKICAgICAgYXR0cmlidXRlIHR5cGUgeyAiVEVYVCIgfCAiSFRNTCIgfCBhdG9tTWVkaWFUeXBl IH0/LAogICAgICAodGV4dCkqCiAgIH0KCmF0b21JbmxpbmVYSFRNTENvbnRlbnQgPQogICBlbGVt ZW50IGF0b206Y29udGVudCB7CiAgICAgIGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAgICBhdHRy aWJ1dGUgdHlwZSB7ICJYSFRNTCIgfCBhdG9tTWVkaWFUeXBlIH0/LAogICAgICAodGV4dHxhbnlF bGVtZW50KSoKICAgfQoKYXRvbU91dE9mTGluZUNvbnRlbnQgPQogICBlbGVtZW50IGF0b206Y29u dGVudCB7CiAgICAgIGF0b21Db21tb25BdHRyaWJ1dGVzLAogICAgICBhdHRyaWJ1dGUgdHlwZSB7 ICJURVhUIiB8ICJIVE1MIiB8ICJYSFRNTCIgfCBhdG9tTWVkaWFUeXBlIH0/LAogICAgICBhdHRy aWJ1dGUgc3JjIHsgYXRvbVVyaSB9LAogICAgICBlbXB0eQogICB9CgphdG9tQ29udGVudCA9IGF0 b21JbmxpbmVUZXh0Q29udGVudAogfCBhdG9tSW5saW5lWEhUTUxDb250ZW50CiB8IGF0b21PdXRP ZkxpbmVDb250ZW50CgojIExvdy1sZXZlbCBzaW1wbGUgdHlwZXMKCiMgVE9ETzogY2FuIGFueXRo aW5nIG1vcmUgc3BlY2lmaWMgYmUgc2FpZCBhYm91dCB0aGVzZSB0eXBlcz8KCmF0b21OQ05hbWUg PSB4c2Q6c3RyaW5nIHsgbWluTGVuZ3RoID0gIjEiIHBhdHRlcm4gPSAiW146XSoiIH0KYXRvbU1l ZGlhVHlwZSA9IHRleHQKYXRvbUxhbmd1YWdlVGFnID0gdGV4dAphdG9tVXJpID0gdGV4dAphdG9t RW1haWxBZGRyZXNzID0gdGV4dAoKIyBFeHRlbnNpYmlsaXR5CgphbnlGb3JlaWduRWxlbWVudCA9 CiAgIGVsZW1lbnQgKiAtIChhdG9tOiogfCBsb2NhbDoqKQogICB7CiAgICAgIChhdHRyaWJ1dGUg KiB7IHRleHQgfQogICAgICAgfCB0ZXh0CiAgICAgICB8IGFueUZvcmVpZ25FbGVtZW50KSoKICAg fQoKYW55Rm9yZWlnbkF0dHJpYnV0ZSA9CiAgIGF0dHJpYnV0ZSAqIC0gKGF0b206KiB8IGxvY2Fs OiogfCB4bWw6KikgeyB0ZXh0IH0KCmFueUVsZW1lbnQgPQogICBlbGVtZW50ICogLSBhdG9tOioK ICAgewogICAgICAoYXR0cmlidXRlICogeyB0ZXh0IH0KICAgICAgIHwgdGV4dAogICAgICAgfCBh bnlFbGVtZW50KSoKICAgfQoKIyBFT0YK --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Be seeing you, norm =2D-=20 Norman Walsh | 'Heartless Cynics,' the young men http://nwalsh.com/ | shout, / Blind to the world of Fact | without; / 'Silly Dreamers,' the old | men grin / Deaf to the world of Purpose | within.--W. H. Auden --=-=-=-- --==-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCAqcmOyltUcwYWjsRAmifAKCKNnxrrd8bz60Npk7KCGkGg7f+CwCfb4gE WYkDutorRza+jcqFviiJ+gs= =JWHt -----END PGP SIGNATURE----- --==-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 17:54:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02548 for ; Thu, 3 Feb 2005 17:54:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MkUE3060756; Thu, 3 Feb 2005 14:46:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MkUxW060755; Thu, 3 Feb 2005 14:46:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13MkTD6060748 for ; Thu, 3 Feb 2005 14:46:30 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13MkTVu016381 for ; Thu, 3 Feb 2005 15:46:29 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBC003VHXXB7Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 03 Feb 2005 15:46:23 -0700 (MST) Received: from [10.192.52.83] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBC005FKXX9UN@mail.sun.net> for atom-syntax@imc.org; Thu, 03 Feb 2005 15:46:22 -0700 (MST) Date: Thu, 03 Feb 2005 14:46:32 -0800 From: Tim Bray Subject: Re: RELAX NG Grammar question In-reply-to: <87acql71po.fsf@nwalsh.com> To: Norman Walsh Cc: Atom Syntax Message-id: <66dba0a7b593af288d3b93a968036631@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <87acql71po.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 3, 2005, at 1:50 PM, Norman Walsh wrote: > There are some constraints that the RELAX NG grammar can't practically > enforce. Should it enforce the MUSTs of the specification or the > SHOULDs? > For example, should it allow non-XHTML elements inside a Content > Construct with the type 'XHTML'? Ideally we'd like two versions, or maybe some Schematron trickery so we get told about SHOULDs but it doesn't actually fail? As for the XHTML thing, I think this is going to happen all the time (foreign markup in embedded XHTML) and I don't think we should try to get in the way. However, I just now tried to think of some spec language to express this and came up empty. -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 18:01:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03181 for ; Thu, 3 Feb 2005 18:01:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13Mkhrn060808; Thu, 3 Feb 2005 14:46:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13MkhjJ060806; Thu, 3 Feb 2005 14:46:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13Mkg7e060783 for ; Thu, 3 Feb 2005 14:46:42 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j13Mkgdt028546 for ; Thu, 3 Feb 2005 15:46:42 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBC003L9XXS8T@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 03 Feb 2005 15:46:41 -0700 (MST) Received: from [10.192.52.83] ([192.18.45.134]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBC005FKXX9UN@mail.sun.net> for atom-syntax@imc.org; Thu, 03 Feb 2005 15:46:40 -0700 (MST) Date: Thu, 03 Feb 2005 14:46:52 -0800 From: Tim Bray Subject: Re: Exactly one atom:contributor? In-reply-to: <87y8e55mj3.fsf@nwalsh.com> To: Norman Walsh Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <87y8e55mj3.fsf@nwalsh.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 3, 2005, at 2:03 PM, Norman Walsh wrote: > I find the constraint that an atom:feed or atom:entry can contain at > most one atom:contributor a little odd. Suppose Tom, Dick, and Harry > work on an entry, why can only two of them get credit (one as author > and one as contributor). Why am I not allowed to indicate that they > each contributed to the entry? I'm pretty sure that's a bug. -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 18:11:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04529 for ; Thu, 3 Feb 2005 18:11:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13N2njr062355; Thu, 3 Feb 2005 15:02:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13N2neU062354; Thu, 3 Feb 2005 15:02:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13N2mKC062347 for ; Thu, 3 Feb 2005 15:02:48 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j13N2mVu028972 for ; Thu, 3 Feb 2005 16:02:48 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBC00M01YHHXV@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Thu, 03 Feb 2005 18:02:48 -0500 (EST) Received: from localhost (vpn-129-150-34-64.Central.Sun.COM [129.150.34.64]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBC008NWYO7O2@bur-mail1.east.sun.com> for atom-syntax@imc.org; Thu, 03 Feb 2005 18:02:48 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cwpz9-0002RC-MJ for atom-syntax@imc.org; Thu, 03 Feb 2005 18:02:03 -0500 X-URL: http://nwalsh.com/ Date: Thu, 03 Feb 2005 18:02:02 -0500 From: Norman Walsh Subject: Re: RELAX NG Grammar question In-reply-to: <66dba0a7b593af288d3b93a968036631@sun.com> To: Atom Syntax Message-id: <87brb14591.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <87acql71po.fsf@nwalsh.com> <66dba0a7b593af288d3b93a968036631@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Tim Bray was heard to say: | On Feb 3, 2005, at 1:50 PM, Norman Walsh wrote: | |> There are some constraints that the RELAX NG grammar can't practically |> enforce. Should it enforce the MUSTs of the specification or the SHOULDs? |> For example, should it allow non-XHTML elements inside a Content |> Construct with the type 'XHTML'? | | Ideally we'd like two versions, or maybe some Schematron trickery so | we get told about SHOULDs but it doesn't actually fail? Ok, I'll plan to spend some more time thinking about the Schematron expressions (and writing some of the hairier ones) after the spec is really bolted down. | As for the XHTML thing, I think this is going to happen all the time (for= eign | markup in embedded XHTML) and I don't think we should try to get in the w= ay. | However, I just now tried to think of some spec language to express this = and | came up empty. -Tim I think the spec language is fine If the value of "type" is "XHTML", the content of the Text construct MAY contain child elements. The content SHOULD be XHTML text and markup that could validly appear directly within an xhtml:div element. Be seeing you, norm =2D-=20 Norman Walsh | Old age is the most unexpected of all http://nwalsh.com/ | the things that happen to a man.-- | Trotsky --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCAq1qOyltUcwYWjsRAgDLAJ9dsv/1gT1xzUbwkhU9dGQ4jaXJjQCfdi/D Cjk5BYvkKtMZkYCzNiX7YTg= =c+jm -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Thu Feb 3 20:10:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14639 for ; Thu, 3 Feb 2005 20:10:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j140ueJG071099; Thu, 3 Feb 2005 16:56:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j140ue3p071098; Thu, 3 Feb 2005 16:56:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j140uZWK071091 for ; Thu, 3 Feb 2005 16:56:35 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j140uVCh014306; Thu, 3 Feb 2005 19:56:32 -0500 (EST) Message-ID: <4202C840.5050003@intertwingly.net> Date: Thu, 03 Feb 2005 19:56:32 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: PaceRemoveVersionAttr References: <878y658hqj.fsf@nwalsh.com> In-Reply-To: <878y658hqj.fsf@nwalsh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > Some thoughts > > - It seems very likely to me that Atom will evolve over time. > > - For some applications, changing the namespace name with every > version is entirely impractical. Atom may or may not be in this > category. Do feeds become legacy? Are people storing entries with > the expectation that the readers of 2014 will be able to display > them, albeit perhaps imperfectly? Changing the namespace makes that > *hard*. XSLT transformations and XML Queries for Namespace1 flatly > will not work with Namespace2. > > - When I look at a feed, I am comforted on some emotional level by my > ability to know what version the creator intended it to be. For me, I'd like the comfort of knowing that a V1.0 feed will continue to be valid with respect to future versions of the specifications, and that tools written to consume V1.0 feeds will continue to work with subsequent versions of the specification. RSS 0.9x (including 2.0) is evidence that the former is possible (I can cite some minor incompatibilities, but these are merely exceptions that prove the rule). I do believe that the latter is also possible. Without ever changing the namespace. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Feb 3 20:11:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA14674 for ; Thu, 3 Feb 2005 20:11:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1410AcB071342; Thu, 3 Feb 2005 17:00:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1410ASI071341; Thu, 3 Feb 2005 17:00:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14104Zr071333 for ; Thu, 3 Feb 2005 17:00:05 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j14101kc001169; Thu, 3 Feb 2005 20:00:02 -0500 (EST) Message-ID: <4202C913.8070108@intertwingly.net> Date: Thu, 03 Feb 2005 20:00:03 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRemoveVersionAttr References: <7ED765BD-7630-11D9-8EFA-003065EA6144@geckotribe.com> In-Reply-To: <7ED765BD-7630-11D9-8EFA-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Thursday, February 3, 2005, at 02:18 PM, Norman Walsh wrote: > >> - It seems very likely to me that Atom will evolve over time. >> >> - For some applications, changing the namespace name with every >> version is entirely impractical. Atom may or may not be in this >> category. Do feeds become legacy? Are people storing entries with >> the expectation that the readers of 2014 will be able to display >> them, albeit perhaps imperfectly? Changing the namespace makes that >> *hard*. XSLT transformations and XML Queries for Namespace1 flatly >> will not work with Namespace2. >> >> - When I look at a feed, I am comforted on some emotional level by my >> ability to know what version the creator intended it to be. > > I used to be fairly attached to being able to see a version number in > the feed, but no longer am, IF the following conditions are met. In the > following, b > a and X != Y--the rest is indeterminate: > > 1) A valid Atom X.a feed is guaranteed to be a valid Atom X.b feed > > 2) An application aware of Atom X.a can safely ignore changes made in > Atom X.b > > 3) The namespace for Atom version X.a is guaranteed to be the same as > for Atom version X.b > > 4) The namespace for Atom version X.a is guaranteed to be different than > the namespace for Atom version Y.c > > 5) X can easily be determined by viewing the namespace for Atom version X.* > > I think this is what we're aiming for, but I'm not certain that we have > approved spec text to ensure it. PaceExtendingAtom addresses some of > this, but not all of it. Do we need something more? That is what I am aiming for. I put some placeholder text at the bottom of PaceRemoveVersionAttr, but it definately needs to be expanded/improved. - Sam Ruby From owner-atom-syntax@mail.imc.org Thu Feb 3 21:26:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19645 for ; Thu, 3 Feb 2005 21:26:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142G2pg077294; Thu, 3 Feb 2005 18:16:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142G1qQ077292; Thu, 3 Feb 2005 18:16:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142Fpxd077273 for ; Thu, 3 Feb 2005 18:15:56 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j142FlVu020159 for ; Thu, 3 Feb 2005 19:15:51 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBD003RV7MB7Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 03 Feb 2005 19:15:47 -0700 (MST) Received: from [10.242.56.112] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBD000V37M28A@mail.sun.net> for atom-syntax@imc.org; Thu, 03 Feb 2005 19:15:39 -0700 (MST) Date: Thu, 03 Feb 2005 18:15:48 -0800 From: Tim Bray Subject: Re: Organization Use Cases (was: Re: Format spec vs Protocol spec) In-reply-to: <420134D3.2090400@franklinmint.fm> To: Robert Sayre Cc: Atom Syntax , Walter Underwood Message-id: <265086a959e5bf339cecb7adb98a8f76@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <41FFEF0D.1090200@gmx.de> <420125F2.7080402@franklinmint.fm> <420134D3.2090400@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote: > 1.) A web forum, where one post serves as the root of a collection of > other posts. > > HTML-- > http://groups-beta.google.com/group/bloggerDev/ > > Atom 0.3, "root" posts only-- > http://groups-beta.google.com/group/bloggerDev/feed/topics.xml > > Atom 0.3, all messages-- > http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml Q: Has any previous flavor of RSS had a solution for this? Potential solutions that occur to me: 1. Ignore the problem 2. PaceEntriesElement could handle this 3. PaceFeedRecursive could handle this 4. PaceAtomHeadInEntry could handle this 5. PaceAggregationDocument could handle this I honestly can't say which I prefer. Would anyone like to try to put together examples of the solution in #2 through #5 so that we can consider the alternatives? > 2.) A Blog w/ comments, where on post serves as the root of a > collection > of other posts. > > HTML-- > http://www.livejournal.com/users/giant_moose/ > > Atom 0.3, no indication of comments-- > http://www.livejournal.com/users/giant_moose/data/atom Q: Has any previous flavor of RSS had a solution for this? Q: Do we have a proposal on something to handle this? I believe there is a proposal for a which would do the job. > 3.) A "List Status" feed, where the only updates consist of one > collection replacing another. > > RSS2 -- > http://rss.netflix.com/Top100RSS > > background info-- > http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd > -4cba-959a-2bba6ae917f0 Q: Has any previous flavor of RSS had a solution for this? Q: Do we have a proposal for something to handle this? Dare points out that the feed suffers from lack of guids and dates, something that Atom would force them to fix, which would give an aggregator a better chance of doing something useful. -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 21:45:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21751 for ; Thu, 3 Feb 2005 21:45:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142bUVw079411; Thu, 3 Feb 2005 18:37:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142bUgc079410; Thu, 3 Feb 2005 18:37:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142bTwV079403 for ; Thu, 3 Feb 2005 18:37:29 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j142bTdt010187 for ; Thu, 3 Feb 2005 19:37:29 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBD003I48MG8T@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 03 Feb 2005 19:37:29 -0700 (MST) Received: from [10.242.56.112] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBD000DW8MF87@mail.sun.net> for atom-syntax@imc.org; Thu, 03 Feb 2005 19:37:28 -0700 (MST) Date: Thu, 03 Feb 2005 18:37:37 -0800 From: Tim Bray Subject: On organization and abstraction To: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On reflection, I am growing very negative on almost all of the "Organization" Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts. I would like it if the markup found in Atom documents was as close as possible to a typical human mental model. The word "feed" has entered the vocabulary, even the non-geek vocabulary, and the notion that there are "things" (entries, stories, items, whatever) in "feeds" likewise. Any attempt to abstract away and generalize along the lines of "well, a feed is really an entry" or "well, an entry is really a feed" or "really, they're all just web resources and collections" is dangerously close to verging on Architecture Astronautics. Put another way, Adam Bosworth, likely one of the best computer programmers in the world, said "every time I add abstraction to an interface I lose 90% of the audience." I would like Atom to be more like Visual Basic and less like Lisp. Put another way, starting in 1986 there was a system called SGML, an ISO standard for marking up documents, which was awesome in its generality; the notion of what a delimiter was, what a character was, what an element was, all these things were entirely abstract. So, it was almost impossible to implement and never really caught on. On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub & friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 21:53:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22666 for ; Thu, 3 Feb 2005 21:53:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142gjXr079772; Thu, 3 Feb 2005 18:42:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142gjag079771; Thu, 3 Feb 2005 18:42:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142giaS079758; Thu, 3 Feb 2005 18:42:45 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j142giVu002833; Thu, 3 Feb 2005 19:42:44 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBD003AR8V87Q@edgemail1.Central.Sun.COM>; Thu, 03 Feb 2005 19:42:44 -0700 (MST) Received: from [10.242.56.112] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBD0000O8V78A@mail.sun.net>; Thu, 03 Feb 2005 19:42:44 -0700 (MST) Date: Thu, 03 Feb 2005 18:42:53 -0800 From: Tim Bray Subject: Re: Call for final Paces for consideration: deadline imminent In-reply-to: To: Paul Hoffman Cc: Atom WG Message-id: <9968b23b270cf6fc51eab8a5ddd7d527@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 2, 2005, at 5:46 PM, Paul Hoffman wrote: ... > On Monday, Feb. 7, the Working Group's final queue rotation will > consist of all Paces open at that time. Any Paces that have obvious > holes in them ("to be filled in later", "more needs to go here", etc.) > will be ignored. We have had over a year of time here, and many weeks > since the previous attempt to close things out. On Monday, Feb. 14, we > will assess WG consensus and ask the document authors to put together > a final draft. ... In case it's not obvious, I am 100% with Paul on this. I think that the Atom format as it stands now is very close to a huge 80/20 point, and the world needs it. Also, I think that one or two of the last outstanding Paces will result in a noticeable positive delta. It's like when you get towards the end of a software project. The engineers always know that they could make it better in just another few weeks' work, and at some point you have to let go and turn it over to the world. Let's get our last round of Paces nicely nailed down and cleaned up and polished and ready to take up officially on Monday. -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 22:02:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24067 for ; Thu, 3 Feb 2005 22:02:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142qT1K080683; Thu, 3 Feb 2005 18:52:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142qTUZ080682; Thu, 3 Feb 2005 18:52:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142qSRI080676 for ; Thu, 3 Feb 2005 18:52:28 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cwta5-0004Kc-BZ; Fri, 04 Feb 2005 02:52:25 +0000 Message-ID: <4202E365.6080105@franklinmint.fm> Date: Thu, 03 Feb 2005 21:52:21 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: On organization and abstraction References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On reflection, I am growing very negative on almost all of the > "Organization" Paces, including FeedRecursive, PaceEntriesElement, > PaceCollection. Here's why: they represent to increase the level of > abstraction in Atom, and in my experience, when the goal is > interoperability across the network, abstraction hurts. There's a diff of your feed in PaceEntriesElement. It's pushing it to claim one is more interoperable than the other. You just asked for examples 15 minutes ago, why don't you wait for them? > The word "feed" has entered the vocabulary, > even the non-geek vocabulary, and the notion that there are "things" > (entries, stories, items, whatever) in "feeds" likewise. None of the "feed formats" out there use the term "feed" in their vocabularies. > Any attempt to > abstract away and generalize along the lines of "well, a feed is really > an entry" or "well, an entry is really a feed" or "really, they're all > just web resources and collections" is dangerously close to verging on > Architecture Astronautics. OK, define "Feed" and "Entry". We haven't done it yet. I think calling other designs "astronautics" is unjustified. HeadInEntry is astronautics in the worst way--just nest them. But hey that's just my opinion. Also, atom:content is architecture astronautics. Base64? Please. HTML in atom:copyright? architecture astronautics. > > Put another way, Adam Bosworth, likely one of the best computer > programmers in the world, said "every time I add abstraction to an > interface I lose 90% of the audience." I would like Atom to be more > like Visual Basic and less like Lisp. This is not a meaningful comparison to me. > > On the other hand, the notion that sometimes you have collections of > feeds is easy to understand, easy to verbalize, and widely evidenced in > practice (cf PubSub & friends), if not perhaps widely seen outside of > geekland. So I think I'm +1 on PaceAggregationDocument. (And I think > if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) I think you should wait for examples. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 22:02:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24128 for ; Thu, 3 Feb 2005 22:02:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142snqE080845; Thu, 3 Feb 2005 18:54:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142snlu080843; Thu, 3 Feb 2005 18:54:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142siMA080831 for ; Thu, 3 Feb 2005 18:54:46 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwtcB-0004Lb-CC; Fri, 04 Feb 2005 02:54:35 +0000 Message-ID: <4202E3E7.2010207@franklinmint.fm> Date: Thu, 03 Feb 2005 21:54:31 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , Walter Underwood Subject: Re: Organization Use Cases References: <41FFEF0D.1090200@gmx.de> <420125F2.7080402@franklinmint.fm> <420134D3.2090400@franklinmint.fm> <265086a959e5bf339cecb7adb98a8f76@sun.com> In-Reply-To: <265086a959e5bf339cecb7adb98a8f76@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Feb 2, 2005, at 12:15 PM, Robert Sayre wrote: > >> 1.) A web forum, where one post serves as the root of a collection of >> other posts. >> >> HTML-- >> http://groups-beta.google.com/group/bloggerDev/ >> >> Atom 0.3, "root" posts only-- >> http://groups-beta.google.com/group/bloggerDev/feed/topics.xml >> >> Atom 0.3, all messages-- >> http://groups-beta.google.com/group/bloggerDev/feed/msgs.xml > > > Q: Has any previous flavor of RSS had a solution for this? By reference, there is wfw:commentrss. That's typing of items/entries by the type of link relation that points to them. That means you're going to have people calling things "comments" to get the interface to happen. It's nesting. > > Potential solutions that occur to me: > > 1. Ignore the problem > 2. PaceEntriesElement could handle this > 3. PaceFeedRecursive could handle this > 4. PaceAtomHeadInEntry could handle this > 5. PaceAggregationDocument could handle this > > I honestly can't say which I prefer. Would anyone like to try to put > together examples of the solution in #2 through #5 so that we can > consider the alternatives? > I will put together examples for all of the alternatives, and I will add one more example: planetsun.org. >> 2.) A Blog w/ comments, where on post serves as the root of a collection >> of other posts. >> >> HTML-- >> http://www.livejournal.com/users/giant_moose/ >> >> Atom 0.3, no indication of comments-- >> http://www.livejournal.com/users/giant_moose/data/atom > > > Q: Has any previous flavor of RSS had a solution for this? No, but the problem isn't that hard. I wouldn't be surprised if LJ has some private format for this, but I don't know if they do. > Q: Do we have a proposal on something to handle this? PaceEntriesElement would do it. > > I believe there is a proposal for a which would do > the job. It wouldn't handle that example. The comments are nested. XML elements nest pretty well. It would handle the first case... but only by reference. You couldn't "subscribe to posts with comments". > >> 3.) A "List Status" feed, where the only updates consist of one >> collection replacing another. >> >> RSS2 -- >> http://rss.netflix.com/Top100RSS >> >> background info-- >> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd >> -4cba-959a-2bba6ae917f0 > > > Q: Has any previous flavor of RSS had a solution for this? Yes. http://npg.nature.com/pdf/newsfeeds.rdf, or there is OPML. > Q: Do we have a proposal for something to handle this? > Yes, any of the "organization" Paces would take care of this, other than the ordering problem, which no Pace addresses. > Dare points out that the feed suffers from lack of guids and dates, > something that Atom would force them to fix, which would give an > aggregator a better chance of doing something useful. -Tim > Nesting collections would make the situation explicit. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 22:07:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24847 for ; Thu, 3 Feb 2005 22:07:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142sulO080866; Thu, 3 Feb 2005 18:54:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j142sumc080865; Thu, 3 Feb 2005 18:54:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j142snoA080826 for ; Thu, 3 Feb 2005 18:54:56 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j142sPqn005969 for ; Thu, 3 Feb 2005 21:54:26 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNG75999 (AUTH bob@wyman.us); Thu, 3 Feb 2005 21:54:24 -0500 (EST) Message-Id: <200502040254.CNG75999@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: Subject: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...) Date: Thu, 3 Feb 2005 21:50:51 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001C_01C50A3A.6EF88990" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUKZFaMZjOexIuWQiOK2OMbuZlVLQ== Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. ------=_NextPart_000_001C_01C50A3A.6EF88990 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit At PubSub.com, we've started generating "CAP over Atom" files. By this I mean we're publishing using Atom files to encapsulate a stream of message which are encoded using the CAP (Common Alerting Protocol) format. See: http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core -1.0.pdf . Because CAP is an XML format, we're using atom:content elements with type="text/xml". In order to ensure that there is something for aggregators to display if they don't understand CAP, we're generating atom:summary elements that contain a textual summary of the CAP message which is in the atom:content. My hope is that aggregator developers will commonly implement a pattern of displaying the atom:summary rather then the atom:content in cases where they don't understand the XML type of the content element. I would appreciate any review comments that you might be able to make on our use of Atom in this application. For a sample Atom feed containing CAP messages which describe recent earthquakes, please see: http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml A sample atom:entry extracted from this Atom Feed is below: /pubsub/topics/301 <![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z ]]> 2005-02-03T21:04:42-05:00 2005-02-03T21:04:42-05:00 tag:pubsub.com,2005:CAP:nc51156375 An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) nc51156375 earthquakes@pubsub.com 2005-02-03T21:04:42-05:00 Test Alert Public nc51156375 Geo Earthquake Unknown Unknown Unknown Pubsub Earthquake Service Earthquake: M 1.6 (D) NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and should not be considered authoritative.) http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm EventID=nc51156375 Version=1 Magnitude=1.6 MD Depth=2 km Verified=N 2 km depth at latitude 38.8168, longitude -122.7915 at location: NORTHERN CALIFORNIA 38.8168,-122.7915 0 Note: I am aware of a few issues with our current use of Atom: 1. We often issue files that contain more than one entry with the same atom:id. For instance, you might have a message which is followed in the file by an update concerning the same "incident" or a "Cancel" message for the event. I know this is a violation of the specification. We will eventually stop doing this. Please bear with us. 2. We currently don't provide an atom:link element with rel="alternate" when we insert a CAP "Cancel" message into the feed. This is, of course, because we have no page to point to for a deleted or cancelled event. In the future, we'll consider having all such Cancel messages point to a common static help page which explains a variety of reasons why a message may have been deleted. 3. If you view the Atom feed in a web browser, the result may not be terribly pleasing. We're still working on the style sheet. - Please pay attention only to the source of the feed. (i.e. do "View Source"). This service compliments the Earthquake service that I recently mentioned on this list. We will be publishing both raw Earthquake messages/feeds as well as CAP messages/feed in the future. These two formats are targeted at different audiences. Your comments and/or suggestions would be appreciated. bob wyman ------=_NextPart_000_001C_01C50A3A.6EF88990 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

At PubSub.com, we’ve = started generating “CAP over Atom” files. By this I mean we’re publishing using Atom files to encapsulate a stream of message which are encoded using the CAP (Common Alerting Protocol) format. See: http://www.oasis-open.org/committees/download.php/63= 34/oasis-200402-cap-core-1.0.pdf .

Because CAP is an XML = format, we’re using atom:content elements with type=3D”text/xml”. In order = to ensure that there is something for aggregators to display if they = don’t understand CAP, we’re generating atom:summary elements that = contain a textual summary of the CAP message which is in the atom:content. My hope = is that aggregator developers will commonly implement a pattern of = displaying the atom:summary rather then the atom:content in cases where they don’t understand = the XML type of the content element.

I would appreciate any = review comments that you might be able to make on our use of Atom in this = application.

For a sample Atom feed containing CAP messages which describe recent earthquakes, please see:

http= ://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml

         =    A sample atom:entry extracted from this Atom Feed is = below:

 

<entry>

<ps:nodeID>/pubsub/topics/301</ps:nodeID><= o:p>

<title><![CDATA[ Earthquake: M 1.6 (D) = NORTHERN CALIFORNIA 2005-02-04T02:00:43.100Z = ]]></title>

<issued>2005-02-03T21:04:42-05:00</issued>=

<modified>2005-02-03T21:04:42-05:00</modified= >

<id>tag:pubsub.com,2005:CAP:nc51156375</id>= ;

<link rel=3D'alternate' type=3D'text/html' href=3D'http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/>= ;

<summary>An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude 1.6 event has been located in = NORTHERN CALIFORNIA. (This is a = computer-generated message and should not be considered authoritative.) = </summary>

<content = type=3D'text/xml'>

<alert xmlns=3D"http://www.incident.com/cap/1.0">=

      = <identifier>nc51156375</identifier><= /p>

      <sender>earthquakes@pubsub.com</sender>

      <sent>2005-02-03T21:04:42-05:00</sent>

      <status>Test</status>

      <msgType>Alert</msgType>

      <scope>Public</scope>

      <incidents>nc51156375</incidents>

      = <info>

        <category>Geo</category>

        <event>Earthquake</event>

        <urgency>Unknown</urgency>

        <severity>Unknown</severity>

        <certainty>Unknown</certainty>

        <senderName>Pubsub Earthquake = Service</senderName>

        = <headline>Earthquake: M 1.6 (D) NORTHERN CALIFORNIA = 2005-02-04T02:00:43.100Z</headline>

        <description>An earthquake occurred at 2005-02-04T02:00:43.100Z. = The magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a computer-generated message and = should not be considered authoritative.) = </description>

        <web>http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm&l= t;/web>

        <parameter>EventID=3Dnc51156375</parameter>=

        <parameter>Version=3D1</parameter>

        <parameter>Magnitude=3D1.6 = MD</parameter>

        <parameter>Depth=3D2 = km</parameter>

        <parameter>Verified=3DN</parameter><= /p>

        = <area>

         = <areaDesc>2 km depth at latitude 38.8168, longitude -122.7915 at location: NORTHERN = CALIFORNIA</areaDesc>

         = <circle>38.8168,-122.7915 = 0</circle>

        = </area>

      = </info>

    = </alert>

</content>

</entry>

 

Note: I am aware of a few issues with our current use = of Atom:

1.       = We often issue files that contain more than one entry with the same atom:id. For = instance, you might have a message which is followed in the file by an update = concerning the same “incident” or a “Cancel” message for the = event. I know this is a violation of the specification. We will eventually stop = doing this… Please bear with us.

2.       = We currently don’t provide an atom:link element with = rel=3D”alternate” when we insert a CAP “Cancel” message into the feed. This is, of = course, because we have no page to point to for a deleted or cancelled event. In = the future, we’ll consider having all such Cancel messages point to a = common static help page which explains a variety of reasons why a message may = have been deleted.

3.       = If you view the Atom feed in a web browser, the result may not be terribly = pleasing… We’re still working on the style sheet. – Please pay = attention only to the source of the feed… (i.e. do “View = Source”).

 

This service compliments the Earthquake service that = I recently mentioned on this list. We will be publishing both raw Earthquake = messages/feeds as well as CAP messages/feed in the future. These two formats are = targeted at different audiences.

 

Your comments and/or suggestions would be = appreciated.

 

         =             &= nbsp;  bob wyman

 

------=_NextPart_000_001C_01C50A3A.6EF88990-- From owner-atom-syntax@mail.imc.org Thu Feb 3 22:19:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25769 for ; Thu, 3 Feb 2005 22:18:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1437fEh082998; Thu, 3 Feb 2005 19:07:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1437fJt082997; Thu, 3 Feb 2005 19:07:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1437ear082979 for ; Thu, 3 Feb 2005 19:07:41 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j1436Oc1009127; Fri, 4 Feb 2005 03:06:30 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-4-330165818; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: On organization and abstraction Date: Fri, 4 Feb 2005 03:06:24 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-4-330165818 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 2:37 am, Tim Bray wrote: > On the other hand, the notion that sometimes you have collections of > feeds is easy to understand, easy to verbalize, and widely evidenced > in practice (cf PubSub & friends), if not perhaps widely seen outside > of geekland. So I think I'm +1 on PaceAggregationDocument. (And I > think if we adopted that we could certainly lose PaceHeadInEntry, > right Bob?) If you removed the ability to have entries within the feeds in aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally different task. A collection of feeds would be something like a list of blogs about a certain topic? You get all the information you need in the feed-head, and supplying entries is fairly redundant. Essentially supplying recent entries from those feeds would be extra metadata about the feed. Whereas something like Feedster search results are a collection of entries that come from various blogs. It's the entries the user is interested in, and knowing which feed they came from is essentially extra metadata about the entry. Graham --Apple-Mail-4-330165818 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA0MDMwNjI0WjAjBgkqhkiG9w0BCQQxFgQUStHLpB7ub7D9b3UEXtQQO+GI 5kIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAT2jBa++WJJ341Sj3zzgF5LUc nKet4U6Xe72MgEu+L5ivKsU7EX4DdyPXR3Y01bWcmKaJRAum1MYOJB8zUb5caWgjeQ9RsWo56UXU ilM3hV+PFxI1nMpSnary1WnPRyopDYlzVXu+WdP4XI45OltUsS6zgb7AljUQ3iT18ppYH/lyxoGE SQnv62VdbQha9XTxcQVI2sO5Q+uE82nhHv8QOADLaH8QABW0c7TI4JisG+DTm8nJQ3XsohExaCBW qK3P9Xe7Ub4RlDKeipUPjSYE1Gtj2N65dMMuxRladnbwkmx3AM+7immeAo0qntlfvefUl8wa+pFS 1EXwkbblWQTt+AAAAAAAAA== --Apple-Mail-4-330165818-- From owner-atom-syntax@mail.imc.org Thu Feb 3 22:28:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26365 for ; Thu, 3 Feb 2005 22:28:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143EGBg083661; Thu, 3 Feb 2005 19:14:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143EGqU083660; Thu, 3 Feb 2005 19:14:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143EANE083488 for ; Thu, 3 Feb 2005 19:14:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 16:14:21 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 14:13:32 +1100 Subject: Re: Organization Use Cases From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4202E3E7.2010207@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 1:54 PM, "Robert Sayre" wrote: >> I believe there is a proposal for a which would do >> the job. > > It wouldn't handle that example. The comments are nested. XML elements > nest pretty well. It would handle the first case... but only by > reference. You couldn't "subscribe to posts with comments". I know of at least one blog where the comments are neither hierarchical nor flat ... each comment can be in reply to multiple previous comments. How would you model this in XML? I would use and (guessing at the @rel values) e. From owner-atom-syntax@mail.imc.org Thu Feb 3 22:31:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26609 for ; Thu, 3 Feb 2005 22:31:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143Jcng084219; Thu, 3 Feb 2005 19:19:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143JccU084218; Thu, 3 Feb 2005 19:19:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143JbES084211 for ; Thu, 3 Feb 2005 19:19:37 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cwu0O-0004VB-9g; Fri, 04 Feb 2005 03:19:36 +0000 Message-ID: <4202E9C4.8060500@franklinmint.fm> Date: Thu, 03 Feb 2005 22:19:32 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Tim Bray , Atom Syntax Subject: Re: On organization and abstraction References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 4 Feb 2005, at 2:37 am, Tim Bray wrote: > >> On the other hand, the notion that sometimes you have collections of >> feeds is easy to understand, easy to verbalize, and widely evidenced >> in practice (cf PubSub & friends), if not perhaps widely seen outside >> of geekland. So I think I'm +1 on PaceAggregationDocument. (And I >> think if we adopted that we could certainly lose PaceHeadInEntry, >> right Bob?) > > > If you removed the ability to have entries within the feeds in > aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally > different task. Why in the world should we define some other document format? OPML will do that just fine. Robert Sayre From owner-atom-syntax@mail.imc.org Thu Feb 3 22:32:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26755 for ; Thu, 3 Feb 2005 22:32:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143QCQs084614; Thu, 3 Feb 2005 19:26:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143QC1v084613; Thu, 3 Feb 2005 19:26:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143QBCs084607 for ; Thu, 3 Feb 2005 19:26:12 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 16:26:57 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 14:26:08 +1100 Subject: Re: PaceAggregationDocument (was: On organization and abstraction) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 2:06 PM, "Graham" wrote: > If you removed the ability to have entries within the feeds in > aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally > different task. > > A collection of feeds would be something like a list of blogs about a > certain topic? You get all the information you need in the feed-head, > and supplying entries is fairly redundant. Essentially supplying recent > entries from those feeds would be extra metadata about the feed. I think the purpose of PaceAggregationDocument is to provide a means to subscribe to an intermediary aggregator like pubsub, and thus receive entries. A collection of feeds for the purpose of a blog roll (ie. no entries) can be modelled in atom as it currently stands - each entry is descriptive about some resource, being a feed, and you'd just have a to the feed itself. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 22:32:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26789 for ; Thu, 3 Feb 2005 22:32:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143QGwt084629; Thu, 3 Feb 2005 19:26:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143QGbZ084628; Thu, 3 Feb 2005 19:26:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143QFmc084622 for ; Thu, 3 Feb 2005 19:26:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 16:27:01 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 14:26:12 +1100 Subject: Re: Organization Use Cases (was: Re: Format spec vs Protocol spec) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <265086a959e5bf339cecb7adb98a8f76@sun.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 1:15 PM, "Tim Bray" wrote: >> 3.) A "List Status" feed, where the only updates consist of one >> collection replacing another. >> >> RSS2 -- >> http://rss.netflix.com/Top100RSS >> >> background info-- >> http://www.25hoursaday.com/weblog/PermaLink.aspx?guid=a257ba40-b9fd >> -4cba-959a-2bba6ae917f0 > > Q: Has any previous flavor of RSS had a solution for this? > Q: Do we have a proposal for something to handle this? > > Dare points out that the feed suffers from lack of guids and dates, > something that Atom would force them to fix, which would give an > aggregator a better chance of doing something useful. -Tim This is not too much unlike how Nature Publishing Group is providing RSS1.0 feeds of table of contents for each issue of their journals. They have one feed URI for each issue, and a 304 redirect on the "current issue" feed URI. Each article has a unique id. They also have an RSS feed where each item is a link to each of their various journal titles. They could also quite reasonably have a per-title feed where each item is a link to each issue's feed. e. From owner-atom-syntax@mail.imc.org Thu Feb 3 22:36:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27238 for ; Thu, 3 Feb 2005 22:36:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143PQPG084585; Thu, 3 Feb 2005 19:25:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j143PQre084584; Thu, 3 Feb 2005 19:25:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j143PPer084578 for ; Thu, 3 Feb 2005 19:25:25 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j143POVu022398 for ; Thu, 3 Feb 2005 20:25:24 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBD002C4AUCFA@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Thu, 03 Feb 2005 20:25:24 -0700 (MST) Received: from [10.242.56.112] ([208.54.15.1]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBD005VOAUBUN@mail.sun.net> for atom-syntax@imc.org; Thu, 03 Feb 2005 20:25:24 -0700 (MST) Date: Thu, 03 Feb 2005 19:25:33 -0800 From: Tim Bray Subject: Re: On organization and abstraction In-reply-to: To: Graham Cc: Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 3, 2005, at 7:06 PM, Graham wrote: >> On the other hand, the notion that sometimes you have collections of >> feeds is easy to understand, easy to verbalize, and widely evidenced >> in practice (cf PubSub & friends), if not perhaps widely seen outside >> of geekland. So I think I'm +1 on PaceAggregationDocument. (And I >> think if we adopted that we could certainly lose PaceHeadInEntry, >> right Bob?) > > If you removed the ability to have entries within the feeds in > aggregation documents, I'm in. PaceHeadInEntry covers a fundamentally > different task. I'm claiming they do the same thing. Instead of f1 f1 e1 f1 e2 f2 e3 you'd have f1 f1 e1 e2 f2> e3 Which on the face of it seems like an improvement. -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 23:31:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01459 for ; Thu, 3 Feb 2005 23:31:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144KFrR089077; Thu, 3 Feb 2005 20:20:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144KFn6089075; Thu, 3 Feb 2005 20:20:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144JmdR088711 for ; Thu, 3 Feb 2005 20:19:59 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 77A3A51A49; Thu, 3 Feb 2005 23:17:33 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63e2637b4f5cde830343778bb9722713@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceExtendingAtom Date: Thu, 3 Feb 2005 20:17:30 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > This specification describes Atom's XML markup vocabulary. > Markup from > other vocabularies ("foreign markup") can be used in Atom in a > variety of > ways. Text Constructs may contain foreign markup which SHOULD > be HTML or > XHTML. What does this statement add? Why is HTML or XHTML normatively preferred over text, MathML, or any other vocabulary? > ==== 9.2 Extensions To the Atom Vocabulary ==== > > Future versions of this specification may add new elements and > attributes > to the Atom markup vocabulary. What about extensions to the specification (as opposed to future versions)? > Software written to conform to this version > of the specification will not be able to process such markup > correctly and, > in fact, will not be able to distinguish it from a markup > error. For the > purposes of this discussion, unrecognized markup from the Atom > vocabulary > will be considered "foreign markup". > > Unlike markup from other vocabularies, foreign markup from the > Atom > vocabulary MAY appear at any location in an Atom document. *Anywhere*? As the root element? As attributes? As as child of atom:id? This is too permissive; it makes it too easy to change the semantics of an element or structure in an incompatible manner. Remember, Atom is a data format, not a markup format. > When unknown foreign markup is encountered as a child of > atom:entry, > atom:head, or a Person Construct, software SHOULD bypass the > markup and any > textual content and MUST NOT change its behavior as a result > of the > markup's presence. Good, but what about requiring someone to understand an extension? If we don't introduce this before we go 1.0, we won't be able to introduce it until Atom 2.0 (I.e., never). This was the wall that HTTP hit, and one of the major drivers towards SOAP; I'd really prefer to avoid it this time around. > When unknown foreign markup is encountered in a Text Contruct > or > atom:content element, software SHOULD ignore the markup and > process any > text content of foreign elements as though the surrounding > markup were not > present. This is bad. If I put a strict media type in my atom:content, I expect its requirements, restrictions and semantics to be honoured; if I'm required to hand it off to a processor, and have that processor understand arbitrary extensions, it's too high a bar; many formats and processors won't be designed to deal with that. Ignoring the markup but processing the text may have unintended consequences. Might I suggest: Extensions are allowed as: - Child elements of atom:head - Child elements of atom:entry - Child elements of elements which are Person constructs - Where particular elements defined by extension explicitly allow it. Anywhere else, it's not an Atom Document. Furthermore, children of atom:head and atom:entry MAY have a mustUnderstand attribute, with the usual semantics. Finally, extensions MUST NOT contradict their containing elements' semantics. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Feb 3 23:32:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01563 for ; Thu, 3 Feb 2005 23:32:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144Lo2n089277; Thu, 3 Feb 2005 20:21:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144Lo0A089276; Thu, 3 Feb 2005 20:21:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144LnZr089269 for ; Thu, 3 Feb 2005 20:21:50 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 107E151A65; Thu, 3 Feb 2005 23:21:48 -0500 (EST) In-Reply-To: <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> References: <92798DAC-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f505012417187d37ae78@mail.gmail.com> <08F07334-6E70-11D9-9797-000A95A51C9E@textuality.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <819eca6d73a2eb838bcab42db0ae59a1@mnot.net> Content-Transfer-Encoding: 7bit Cc: Joe Gregorio , Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceEnclosuresAndPix status Date: Thu, 3 Feb 2005 20:21:47 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just a point of data; most logos are designed to look good at a 1-to-1 aspect ratio. On Jan 24, 2005, at 5:25 PM, Tim Bray wrote: > > > 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 1 > (vertical)? -Tim > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Feb 3 23:33:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01695 for ; Thu, 3 Feb 2005 23:33:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144PqZn089715; Thu, 3 Feb 2005 20:25:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144PqaN089714; Thu, 3 Feb 2005 20:25:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144PpB2089707 for ; Thu, 3 Feb 2005 20:25:51 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 3978351A4B; Thu, 3 Feb 2005 23:25:51 -0500 (EST) In-Reply-To: <1311114903.20050203001838@djpowell.net> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8d352b08be6964ebc999a535e9c13f76@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Thu, 3 Feb 2005 20:25:50 -0800 To: David Powell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My preference would be something like This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, unless a specific ordering is required by an extension. (I.e., I could come up with the UseLexicalOrdering extension, and require processors to understand it to use the feed, assuming our extensibility model supports that, which I very much hope it will). Seem reasonable? On Feb 2, 2005, at 4:18 PM, David Powell wrote: > This specification assigns no significance to the order of > atom:entry elements within the feed. Processors MAY present entries in > a different order to which they are appear in an Atom Feed Document. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Feb 3 23:34:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01755 for ; Thu, 3 Feb 2005 23:34:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144JWZw088961; Thu, 3 Feb 2005 20:20:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144IrXB088519; Thu, 3 Feb 2005 20:18:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144CVwV088265 for ; Thu, 3 Feb 2005 20:13:56 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j144CHG6002931; Thu, 3 Feb 2005 23:12:17 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNG98291 (AUTH bob@wyman.us); Thu, 3 Feb 2005 23:12:16 -0500 (EST) Message-Id: <200502040412.CNG98291@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" , "'Atom Syntax'" Subject: RE: On organization and abstraction Date: Thu, 3 Feb 2005 23:08:43 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUKZGbwkyHXthmRTzKxiZfEw/VFBgAB8ETw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > So I think I'm +1 on PaceAggregationDocument. (And I think > if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -1... PaceAggregationDocument does not seem to me to add much benefit for all the costs that it entails. I'm particularly concerned that adding a new type of root document "aggregation" is likely to add enough to the complexity of Atom that only a subset of developers will actually get around to supporting this third type of document -- a type which doesn't exist in the simple RSS aggregators that exist today. I see two non-compelling benefits to PaceAggregationDocument over PaceHeadInEntry: 1. In the case where a feed will contain more than one entry from a "foreign" feed, you only have to include the atom:head data once. Thus, there would be some increase in efficiency of encoding... However, as I've pointed out on numerous occasions, this is a rare case. Typically, at PubSub, we DO NOT see many cases where atom:head information is repeated in a single instance of a feed. 2. It is easier to see how one would sign an aggregated entry since you don't muck with the contents of entry by inserting the HeadInEntry. This problem, however, would be solved by canonicalization rules that said that you should remove HeadInEntry before processing signatures, or, rules that said that you had to insert HeadInEntry before signing anything, or filter rules that allowed one to flag HeadInEntry as not part of the signed content. (i.e. alternative solutions exist...) But, there are tremendous problems with the proposal: 1. It looks like I can't intersperse "native" entries with aggregated entries. This is a nuisance. I would like to see people insert entries with "HeadInEntry" when they copy something from another feed into their own feed. PaceAggregationDocument says that your feed must have either "native" entries or "foreign" entries, but it can't have both. This seems like an unnecessary constraint. 2. As mentioned before, the introduction of a new level of abstraction (i.e. aggregation) is likely to scare off a good proportion of the aggregator developers. Current aggregators don't have the concept of "aggregation" in them. Thus, new design and new architecture will be required to address this Pace. On the other hand, staying with HeadInEntry is much more gentle on the existing systems and thus much more likely to be useful in the field. 3. Since there will be at least some subset of aggregators that won't understand the "aggregation" thing, it is likely that we'll have a chicken and egg problem. No one will produce "aggregation" documents since not everyone supports them. Thus, no one will support them since no one generates them. On the other hand, HeadInEntry will slide past minimally updated aggregators with no trouble -- i.e. folk who don't want to do the work of handling the stuff properly will simply ignore the Head element... (i.e. it would be suicide for producers like PubSub to support PaceAggregationDocument.) 4. Massive changes need to be made to the specification when we don't have a great deal of time left before we're supposed to be doing a "Last Call." This is dangerous. -1. I really don't see any compelling benefit in exchange for the tremendous risk and cost of accepting PaceAggregationDocument and dropping HeadInEntry. Let's avoid adding to the levels of abstraction here and keep it simple. We should have feeds and entries -- nothing else. > I would like Atom to be more like Visual Basic and less like Lisp. As an ex-Visual Basic Product Manager, I think this would be a good idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to reader: "Visual Basic .NET" is .NOT "Visual Basic"... bob wyman -----Original Message----- From: owner-atom-syntax@mail.imc.org [mailto:owner-atom-syntax@mail.imc.org] On Behalf Of Tim Bray Sent: Thursday, February 03, 2005 9:38 PM To: Atom Syntax Subject: On organization and abstraction On reflection, I am growing very negative on almost all of the "Organization" Paces, including FeedRecursive, PaceEntriesElement, PaceCollection. Here's why: they represent to increase the level of abstraction in Atom, and in my experience, when the goal is interoperability across the network, abstraction hurts. I would like it if the markup found in Atom documents was as close as possible to a typical human mental model. The word "feed" has entered the vocabulary, even the non-geek vocabulary, and the notion that there are "things" (entries, stories, items, whatever) in "feeds" likewise. Any attempt to abstract away and generalize along the lines of "well, a feed is really an entry" or "well, an entry is really a feed" or "really, they're all just web resources and collections" is dangerously close to verging on Architecture Astronautics. Put another way, Adam Bosworth, likely one of the best computer programmers in the world, said "every time I add abstraction to an interface I lose 90% of the audience." I would like Atom to be more like Visual Basic and less like Lisp. Put another way, starting in 1986 there was a system called SGML, an ISO standard for marking up documents, which was awesome in its generality; the notion of what a delimiter was, what a character was, what an element was, all these things were entirely abstract. So, it was almost impossible to implement and never really caught on. On the other hand, the notion that sometimes you have collections of feeds is easy to understand, easy to verbalize, and widely evidenced in practice (cf PubSub & friends), if not perhaps widely seen outside of geekland. So I think I'm +1 on PaceAggregationDocument. (And I think if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) -Tim From owner-atom-syntax@mail.imc.org Thu Feb 3 23:34:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01785 for ; Thu, 3 Feb 2005 23:34:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144Rc1Z089881; Thu, 3 Feb 2005 20:27:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144Rc6U089880; Thu, 3 Feb 2005 20:27:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144RbFt089873 for ; Thu, 3 Feb 2005 20:27:37 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CF18351A20; Thu, 3 Feb 2005 23:27:36 -0500 (EST) In-Reply-To: <878y658hqj.fsf@nwalsh.com> References: <878y658hqj.fsf@nwalsh.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9896e13dcccb95b2c199f30f801e77e7@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceRemoveVersionAttr Date: Thu, 3 Feb 2005 20:27:34 -0800 To: Norman Walsh X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit In its present form, I want to get rid of the version attribute. That's not to say that I don't want something with more useful semantics, on a separate axis from the namespace. So, +1 to the Pace. On Feb 3, 2005, at 1:18 PM, Norman Walsh wrote: > Some thoughts > > - It seems very likely to me that Atom will evolve over time. > > - For some applications, changing the namespace name with every > version is entirely impractical. Atom may or may not be in this > category. Do feeds become legacy? Are people storing entries with > the expectation that the readers of 2014 will be able to display > them, albeit perhaps imperfectly? Changing the namespace makes that > *hard*. XSLT transformations and XML Queries for Namespace1 flatly > will not work with Namespace2. > > - When I look at a feed, I am comforted on some emotional level by my > ability to know what version the creator intended it to be. > > - Perhaps YAGNI applies. > > I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down > in the road over it. > > Be seeing you, > norm > > -- > Norman Walsh | Life is a great bundle of little > http://nwalsh.com/ | things.--Oliver Wendell Holmes > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Feb 3 23:37:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01946 for ; Thu, 3 Feb 2005 23:37:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144O9Vb089538; Thu, 3 Feb 2005 20:24:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144O9kD089537; Thu, 3 Feb 2005 20:24:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144O8WU089530 for ; Thu, 3 Feb 2005 20:24:09 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 69EE351A75; Thu, 3 Feb 2005 23:24:08 -0500 (EST) In-Reply-To: <42011C03.5070309@franklinmint.fm> References: <42011C03.5070309@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <0d10ceea13dc576ea28878e66290c69f@mnot.net> Cc: Atom-Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceRemoveInfoAndHost Date: Thu, 3 Feb 2005 20:24:06 -0800 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j144O9WU089531 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit +1 Welcome to the club :) On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote: > > 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 its detractors still oppose it. > Design by committee at its worst. > > Remove atom:info > ------------------- > Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, > it’s easier to shut down a solo raving loony." In the threads on > atom:info, it seems I am playing the role of solo raving loony. So, > let's have the process take over. > > Robert Sayre > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Thu Feb 3 23:38:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02002 for ; Thu, 3 Feb 2005 23:38:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144RORN089856; Thu, 3 Feb 2005 20:27:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144RO1S089855; Thu, 3 Feb 2005 20:27:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144RNCF089849 for ; Thu, 3 Feb 2005 20:27:24 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j144PNqp025274; Thu, 3 Feb 2005 23:25:23 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNH01907 (AUTH bob@wyman.us); Thu, 3 Feb 2005 23:25:21 -0500 (EST) Message-Id: <200502040425.CNH01907@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'David Powell'" , "'Atom Syntax'" Subject: RE: Entry order Date: Thu, 3 Feb 2005 23:21:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: <158887418.20050201230634@djpowell.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUIte0b4MdDjcUmQAyF5ITpARUYVgButxuw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > It looks like this might have got lost accidently when the > atom:head element was introduced. Previously Atom 0.3 said [1]: >> Ordering of the element children of atom:feed element MUST NOT be >> considered significant. +1. The order of entries in an Atom feed should NOT be significant. This is, I think, a very, very important point to make. bob wyman From owner-atom-syntax@mail.imc.org Thu Feb 3 23:53:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA03466 for ; Thu, 3 Feb 2005 23:53:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144cpeg090844; Thu, 3 Feb 2005 20:38:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144cpEG090843; Thu, 3 Feb 2005 20:38:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144cn2P090827 for ; Thu, 3 Feb 2005 20:38:50 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j144clmm001892; Thu, 3 Feb 2005 23:38:47 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNH05087 (AUTH bob@wyman.us); Thu, 3 Feb 2005 23:38:46 -0500 (EST) Message-Id: <200502040438.CNH05087@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Eric Scheid'" , "'Atom Syntax'" Subject: RE: PaceAggregationDocument (was: On organization andabstraction) Date: Thu, 3 Feb 2005 23:35:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-reply-to: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUKaxiTkI0n5SS/T0Ct+exvltI3ywABjtbw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > I think the purpose of PaceAggregationDocument is to provide a > means to subscribe to an intermediary aggregator like pubsub, and > thus receive entries. If that is the motivation, then I think you really should find some other motivation. Frankly, it is exceptionally unlikely that we at PubSub could take the risk of relying on "aggregation" documents since it is probable that it will be quite some time before substantially all aggregators are updated to support them. It is much more likely that a large proportion of existing and new aggregators will rapidly upgrade their Atom 0.3 support to support the Atom 1.0 feed and entry documents -- but not aggregation documents. My experience with past protocol upgrading events leads me to believe that a large percentage of developers will tire once they have the obvious and familiar bits supported and will then release what they claim to be "compliant" code but with "aggregation" support "delayed until next release..." At PubSub, we'll end up with customers complaining that the Atom we're generating is not supported by their aggregators... Folk will accuse us of having "buggy code". Competitors will attack us for screwing our users in some Quixotic quest for "Atom Purity" when we should be addressing user needs by supporting RSS V2.0 and "core Atom"... No thank you. I really don't want to go there. Find some other reason to push aggregation documents. But, whatever you do, PLEASE don't drop HeadInEntry. If you do drop HeadInEntry, we'll just have to keep using the "ps:" namespace to put it back in. For us to support aggregation documents might be politically correct -- if this Pace is accepted, however, it would be suicide from a business point of view. Please don't ask us to do that which we can not do... bob wyman From owner-atom-syntax@mail.imc.org Fri Feb 4 00:02:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04368 for ; Fri, 4 Feb 2005 00:02:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144tAKs091951; Thu, 3 Feb 2005 20:55:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144tAhx091950; Thu, 3 Feb 2005 20:55:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144t40P091934; Thu, 3 Feb 2005 20:55:05 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 22E0151A91; Thu, 3 Feb 2005 23:55:03 -0500 (EST) In-Reply-To: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7067bc6089d1d61057a280f26d2334ee@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom WG X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Thu, 3 Feb 2005 20:55:02 -0800 To: Paul Hoffman , Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter brings up an important point; has, or when will, the drafts be compared to the requirements in the charter? Cheers, On Feb 2, 2005, at 8:36 PM, Walter Underwood wrote: > > The charter says that Atom will work for archiving. We don't know that > it will, and it hasn't been discussed for months. > > Is the current Atom spec sufficient for archiving? If not, we aren't > done. > > wunder > > --On February 2, 2005 5:46:51 PM -0800 Paul Hoffman > wrote: > >> >> 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, and a couple of promises that "I'll write that up as a Pace >> soon". We need to finish soon in order to make our milestone, and I >> believe we can do so gracefully. >> >> On Monday, Feb. 7, the Working Group's final queue rotation will >> consist of all Paces open at that time. Any Paces that have obvious >> holes in them ("to be filled in later", "more needs to go here", >> etc.) will be ignored. We have had over a year of time here, and many >> weeks since the previous attempt to close things out. On Monday, Feb. >> 14, we will assess WG consensus and ask the document authors to put >> together a final draft. >> >> Note that this is not the last opportunity for work on the Atom >> format. For one thing, there are plenty of non-core extensions that >> folks have been mulling over; having the core draft finally finished >> will help those to emerge. Further, we need to do the final work on >> the protocol document. Also, during the formal IETF Last Call, >> discussion of the format draft will be welcome from everyone >> (including people who have not read any of the earlier drafts). >> >> 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. If your idea is >> appropriate as an extension, or is for something that is quite >> similar to something else that has explicitly gotten lack of >> consensus, please do not write a Pace. In the former case, please >> hold your extensions for a few weeks; in the latter case, please >> recognize that asking the WG to > focus on something that they don't want will likely cause us to do a > worse job at carefully reviewing things that we all want. >> >> So, if you have an incomplete Pace now, you have a few more days to >> complete it. Of course, everyone should feel free to continue talking >> about the current Paces now, and to continue to suggest editorial >> changes to the current Internet Draft. >> >> --Paul Hoffman, Director >> --Internet Mail Consortium >> >> > > > > -- > Walter Underwood > Principal Architect, Verity > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 00:08:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04819 for ; Fri, 4 Feb 2005 00:08:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144wXoL092278; Thu, 3 Feb 2005 20:58:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j144wXU8092276; Thu, 3 Feb 2005 20:58:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j144wXrI092242 for ; Thu, 3 Feb 2005 20:58:33 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020404582701100ccdt0e>; Fri, 4 Feb 2005 04:58:27 +0000 Date: Thu, 3 Feb 2005 21:58:25 -0700 Subject: Re: Organization Use Cases Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4202E3E7.2010207@franklinmint.fm> Message-Id: <6714865B-7669-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 07:54 PM, Robert Sayre wrote: >>> 2.) A Blog w/ comments, where on post serves as the root of a >>> collection >>> of other posts. >>> >>> HTML-- >>> http://www.livejournal.com/users/giant_moose/ >>> >>> Atom 0.3, no indication of comments-- >>> http://www.livejournal.com/users/giant_moose/data/atom >> Q: Has any previous flavor of RSS had a solution for this? > > No, but the problem isn't that hard. I wouldn't be surprised if LJ has > some private format for this, but I don't know if they do. > >> Q: Do we have a proposal on something to handle this? > > PaceEntriesElement would do it. > >> I believe there is a proposal for a which would >> do the job. > > It wouldn't handle that example. The comments are nested. XML elements > nest pretty well. It would handle the first case... but only by > reference. You couldn't "subscribe to posts with comments". > I don't see any reason why a feed reader couldn't give you the option of automatically subscribing to the comment feeds that grow off of the posts in a feed and automatically organize those subscriptions hierarchically under the original. Then, if a thread got uninteresting, you could unsubscribe to just that part of it and never have to download that chunk of it again. A slight variation would be to provide a one-click subscription to comments off of the top level, and then automatically subscribe to the threads underneath it--that would require a lot less manual maintenance to avoid overload. If the top level were fully automatic, it would be pretty messy for a high volume site like Slashdot, for example, but a nested comments feed would be worse, since it would be less simple to hack off the uninteresting threads. From owner-atom-syntax@mail.imc.org Fri Feb 4 00:12:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05281 for ; Fri, 4 Feb 2005 00:12:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1453Hkk092716; Thu, 3 Feb 2005 21:03:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1453HWY092715; Thu, 3 Feb 2005 21:03:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1453GVp092709 for ; Thu, 3 Feb 2005 21:03:16 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id BA5FD519FA for ; Fri, 4 Feb 2005 00:03:15 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <9d93e3488ff803c3dfd4ea9223f06352@bea.com> References: <9d93e3488ff803c3dfd4ea9223f06352@bea.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1b107d3ab76c67950c13835cd8365f3f@mnot.net> Content-Transfer-Encoding: 7bit X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Feed State [was: Work Queue Rotation #16] Date: Thu, 3 Feb 2005 21:03:14 -0800 To: Atom WG X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is now PaceNoFeedState; http://www.intertwingly.net/wiki/pie/PaceNoFeedState On Jan 31, 2005, at 3:46 PM, Mark Nottingham wrote: > x. Managing Feed State > > Atom Processors MAY keep state (e.g., metadata in atom:head, entries) > sourced from Atom Feed Documents and combine them with other Atom Feed > Documents, in order to facilitate a contiguous view of the contents of > the feed. The manner in which Atom Feed Documents are combined in > order to reconstruct a feed (including methods of identifying > duplicate entries, updating metadata, and dealing with missing > entries) is out of the scope of this specification, but may be defined > by an extension to Atom. > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 00:14:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05437 for ; Fri, 4 Feb 2005 00:14:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1456wSu092942; Thu, 3 Feb 2005 21:06:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1456wex092941; Thu, 3 Feb 2005 21:06:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1456w0p092935 for ; Thu, 3 Feb 2005 21:06:58 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 6F1FC519FA; Fri, 4 Feb 2005 00:06:57 -0500 (EST) In-Reply-To: <3f1451f5050124170960be6d43@mail.gmail.com> References: <87B5897C-6E66-11D9-9797-000A95A51C9E@textuality.com> <3f1451f5050124170960be6d43@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <83c0762fe44f8c823fadd28ca62d7438@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceFeedState status Date: Thu, 3 Feb 2005 21:06:56 -0800 To: Joe Gregorio X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'm OK with dropping wholefeed; I'll edit the pace to accommodate that. WRT warning users; you realise that putting something in the user manual, README or box of the consumer (e.g., "This product does not manage feed state.") would satisfy that requirement? Would SHOULD make you feel better? Cheers, On Jan 24, 2005, at 5:09 PM, Joe Gregorio wrote: > I am +1 on the //atom:head/atom:link[@rel='prev'], but -1 on > //atom:head/atom:link[@rel='wholefeed'] and -1 on any of the verbage > that makes demands on clients, for example, "Atom consumers MUST warn > users when they do not have the complete state of a feed " > > -joe > > On Mon, 24 Jan 2005 16:17:42 -0800, Tim Bray > wrote: >> >> If there were no further discussion: Like PaceSupersede, this model of >> publishing does not (so far) enjoy consensus support. -Tim >> >> > > > -- > Joe Gregorio http://bitworking.org > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 00:21:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05853 for ; Fri, 4 Feb 2005 00:21:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145FQi0093489; Thu, 3 Feb 2005 21:15:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145FQ9r093487; Thu, 3 Feb 2005 21:15:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145FP4j093481 for ; Thu, 3 Feb 2005 21:15:26 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 79BB1519FA; Fri, 4 Feb 2005 00:15:25 -0500 (EST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63c7fbdc9a756e93e3c2decf0668420f@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: On organization and abstraction Date: Thu, 3 Feb 2005 21:15:23 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 - someone else made a comment about OPML which really hit the spot; if you try to make a format do all things, it does most of them badly... On Feb 3, 2005, at 6:37 PM, Tim Bray wrote: > > On reflection, I am growing very negative on almost all of the > "Organization" Paces, including FeedRecursive, PaceEntriesElement, > PaceCollection. Here's why: they represent to increase the level of > abstraction in Atom, and in my experience, when the goal is > interoperability across the network, abstraction hurts. I would like > it if the markup found in Atom documents was as close as possible to a > typical human mental model. The word "feed" has entered the > vocabulary, even the non-geek vocabulary, and the notion that there > are "things" (entries, stories, items, whatever) in "feeds" likewise. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 00:27:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06434 for ; Fri, 4 Feb 2005 00:27:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145I1RV093662; Thu, 3 Feb 2005 21:18:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145I1wZ093661; Thu, 3 Feb 2005 21:18:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145I0Mp093650 for ; Thu, 3 Feb 2005 21:18:00 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so371383rne for ; Thu, 03 Feb 2005 21:17:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Jec6pc6ji6+d74pR30FrgTixEZsos1o+8XVf19qweWhJ3rbZqUmuuruJ7tberWJX2CDL3DWSwAZeIdhhM0m54duFUrl2esUsSGGpKMkej7BIMa4nds7VX6tuP57/dzoM7Kx5CW360PZu9M3JGKmr9O9vlySdDYlNoVUNbZeztUI= Received: by 10.38.74.15 with SMTP id w15mr13004rna; Thu, 03 Feb 2005 21:17:54 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 21:17:54 -0800 (PST) Message-ID: <2bcdc7c405020321176d17a66d@mail.gmail.com> Date: Thu, 3 Feb 2005 21:17:54 -0800 From: James Snell Reply-To: James Snell To: bob@wyman.us Subject: Re: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...) Cc: atom-syntax@imc.org In-Reply-To: <200502040254.CNG75999@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 References: <200502040254.CNG75999@ms8.netsolmail.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j145I0Mp093655 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit This is excellent to see. I'm glad to see that you were not afraid to break the syntax rules to get things started. :-) The format looks good. On Thu, 3 Feb 2005 21:50:51 -0500, Bob Wyman wrote: > > > > At PubSub.com, we've started generating "CAP over Atom" files. By this I > mean we're publishing using Atom files to encapsulate a stream of message > which are encoded using the CAP (Common Alerting Protocol) format. See: > http://www.oasis-open.org/committees/download.php/6334/oasis-200402-cap-core-1.0.pdf > . > > Because CAP is an XML format, we're using atom:content elements with > type="text/xml". In order to ensure that there is something for aggregators > to display if they don't understand CAP, we're generating atom:summary > elements that contain a textual summary of the CAP message which is in the > atom:content. My hope is that aggregator developers will commonly implement > a pattern of displaying the atom:summary rather then the atom:content in > cases where they don't understand the XML type of the content element. > > I would appreciate any review comments that you might be able to make on our > use of Atom in this application. > > For a sample Atom feed containing CAP messages which describe recent > earthquakes, please see: > > http://atom.pubsub.com/c0/b8/bd62e8e48058c0425193b37ea6.xml > > A sample atom:entry extracted from this Atom Feed is below: > > > > > > /pubsub/topics/301 > > <![CDATA[ Earthquake: M 1.6 (D) NORTHERN CALIFORNIA > 2005-02-04T02:00:43.100Z ]]> > > 2005-02-03T21:04:42-05:00 > > 2005-02-03T21:04:42-05:00 > > tag:pubsub.com,2005:CAP:nc51156375 > > href='http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm'/> > > An earthquake occurred at 2005-02-04T02:00:43.100Z. The magnitude > 1.6 event has been located in NORTHERN CALIFORNIA. (This is a > computer-generated message and should not be considered authoritative.) > > > > > > > nc51156375 > > earthquakes@pubsub.com > > 2005-02-03T21:04:42-05:00 > > Test > > Alert > > Public > > nc51156375 > > > > Geo > > Earthquake > > Unknown > > Unknown > > Unknown > > Pubsub Earthquake Service > > Earthquake: M 1.6 (D) NORTHERN CALIFORNIA > 2005-02-04T02:00:43.100Z > > An earthquake occurred at 2005-02-04T02:00:43.100Z. The > magnitude 1.6 event has been located in NORTHERN CALIFORNIA. (This is a > computer-generated message and should not be considered authoritative.) > > > > http://earthquake.usgs.gov/recenteqsUS/Quakes/nc51156375.htm > > EventID=nc51156375 > > Version=1 > > Magnitude=1.6 MD > > Depth=2 km > > Verified=N > > > > 2 km depth at latitude 38.8168, longitude -122.7915 at > location: NORTHERN CALIFORNIA > > 38.8168,-122.7915 0 > > > > > > > > > > > > > > Note: I am aware of a few issues with our current use of Atom: > > 1. We often issue files that contain more than one entry with the same > atom:id. For instance, you might have a message which is followed in the > file by an update concerning the same "incident" or a "Cancel" message for > the event. I know this is a violation of the specification. We will > eventually stop doing this… Please bear with us. > > 2. We currently don't provide an atom:link element with > rel="alternate" when we insert a CAP "Cancel" message into the feed. This > is, of course, because we have no page to point to for a deleted or > cancelled event. In the future, we'll consider having all such Cancel > messages point to a common static help page which explains a variety of > reasons why a message may have been deleted. > > 3. If you view the Atom feed in a web browser, the result may not be > terribly pleasing… We're still working on the style sheet. – Please pay > attention only to the source of the feed… (i.e. do "View Source"). > > > > This service compliments the Earthquake service that I recently mentioned on > this list. We will be publishing both raw Earthquake messages/feeds as well > as CAP messages/feed in the future. These two formats are targeted at > different audiences. > > > > Your comments and/or suggestions would be appreciated. > > > > bob wyman > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 00:49:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07794 for ; Fri, 4 Feb 2005 00:49:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145bQ8t095386; Thu, 3 Feb 2005 21:37:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145bQRJ095385; Thu, 3 Feb 2005 21:37:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145bQEt095373 for ; Thu, 3 Feb 2005 21:37:26 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so374652rne for ; Thu, 03 Feb 2005 21:37:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Rn0UjRFA8nzwploMXsracM5Za/Oh0+kP8Fjke0PdFnAhM+Q9u72HeZzEkpGCe8D4Q8LdFM+MGLC3taSEO6tkPQgOhT4iaGIuoFekn6JS2SJNUDTzjm5nEBdoWvVHEUp8E3DsvG2ENDH7VHMZViCwToA7GFKfrB6dosSm+UGUepo= Received: by 10.38.71.71 with SMTP id t71mr18020rna; Thu, 03 Feb 2005 21:37:20 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 21:37:20 -0800 (PST) Message-ID: <2bcdc7c405020321371d53a409@mail.gmail.com> Date: Thu, 3 Feb 2005 21:37:20 -0800 From: James Snell Reply-To: James Snell To: bob@wyman.us Subject: Re: On organization and abstraction Cc: Tim Bray , Atom Syntax In-Reply-To: <200502040412.CNG98291@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502040412.CNG98291@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman wrote: > > Tim Bray wrote: > > So I think I'm +1 on PaceAggregationDocument. (And I think > > if we adopted that we could certainly lose PaceHeadInEntry, right Bob?) > -1... > PaceAggregationDocument does not seem to me to add much benefit for > all the costs that it entails. I'm particularly concerned that adding a new > type of root document "aggregation" is likely to add enough to the > complexity of Atom that only a subset of developers will actually get around > to supporting this third type of document -- a type which doesn't exist in > the simple RSS aggregators that exist today. +1 to this -1. The aggregation element is not a necessary part of the core and adds complexity without adding *significant* benefit to the core. > 2. As mentioned before, the introduction of a new level of > abstraction (i.e. aggregation) is likely to scare off a good proportion of > the aggregator developers. Current aggregators don't have the concept of > "aggregation" in them. Thus, new design and new architecture will be > required to address this Pace. On the other hand, staying with HeadInEntry > is much more gentle on the existing systems and thus much more likely to be > useful in the field. This is precisely why I don't think this belongs in the core. For those who need this type of functionality, the opportunity exists for them to create a separate Internet-Draft that describes how to aggregate feeds -- without adding complexity to the core syntax by introducing elements that the vast majority of users will *likely* never use. (I obviously base this assumption on the reasoning that most Atom users will use it as a drop in replacement for RSS). > 3. Since there will be at least some subset of aggregators that > won't understand the "aggregation" thing, it is likely that we'll have a > chicken and egg problem. No one will produce "aggregation" documents since > not everyone supports them. Thus, no one will support them since no one > generates them. Well, I wouldn't go this far. There is obviously a requirement for it for some folks and those folks are likely to make good use of it. What I would rather see the WG do is take a minimalist approach with this. Right now, I see aggregated feeds falling into that limited 20% of use cases that could be done, but aren't necessarily critical to be done. Aggregation could be defined as an extension to Atom, and later, based on an analysis of its implementation over time, can be merged into the Atom core if deemed appropriate. Merging it into the core now does not guarantee that its adoption and use will be any greater than if it were done as an extension. > 4. Massive changes need to be made to the specification when we > don't have a great deal of time left before we're supposed to be doing a > "Last Call." This is dangerous. > +1. Big +1. > -1. I really don't see any compelling benefit in exchange for the > tremendous risk and cost of accepting PaceAggregationDocument and dropping > HeadInEntry. Let's avoid adding to the levels of abstraction here and keep > it simple. We should have feeds and entries -- nothing else. > One point, HeadInEntry solves the problem of having a standalone Atom Entry document be able to reference a feed of which it is a part. Unless I'm misreading something, if PaceAggregationDocument gets rid of the ability to put Head elements in the entry, don't we lose this capability? (this is something that is important, for instance, in my Atom Notification Protocol proposal) > > I would like Atom to be more like Visual Basic and less like Lisp. > As an ex-Visual Basic Product Manager, I think this would be a good > idea! Let's keep it simple and NOT accept PaceAggregationDocument. (Note to > reader: "Visual Basic .NET" is .NOT "Visual Basic"... > Aargh! VB... it burns! (sorry, temporary flashback to past hell. Sorry Bob, VB was an excellent product, I just was forced to be witness to some extremely bad uses of it. Nightmares, I tell you, nightmares!) > bob wyman > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 00:51:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07888 for ; Fri, 4 Feb 2005 00:51:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145ghYh095881; Thu, 3 Feb 2005 21:42:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145ghJ7095880; Thu, 3 Feb 2005 21:42:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145ggqL095865 for ; Thu, 3 Feb 2005 21:42:43 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so375717rne for ; Thu, 03 Feb 2005 21:42:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=ZigEB4Ayx8UujsNxzZNdpYUxb/zIFIu0WScvbdYNOpavBAOzGv/AiZ9cBcFKIRtMetPfhnCyE4FZC09Ba+AbZaEdMpfkEPo90RsM/9jDaUnSifsPwuBY0bntVTPSy6ERT/zJEpDB52vF0NLQSgieBScJ4IMkbV6maA7kNfRxwVQ= Received: by 10.38.151.68 with SMTP id y68mr74964rnd; Thu, 03 Feb 2005 21:42:39 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 21:42:39 -0800 (PST) Message-ID: <2bcdc7c4050203214242f2a584@mail.gmail.com> Date: Thu, 3 Feb 2005 21:42:39 -0800 From: James Snell Reply-To: James Snell To: Mark Nottingham Subject: Re: PaceRemoveInfoAndHost Cc: Robert Sayre , Atom-Syntax In-Reply-To: <0d10ceea13dc576ea28878e66290c69f@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <42011C03.5070309@franklinmint.fm> <0d10ceea13dc576ea28878e66290c69f@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 On Thu, 3 Feb 2005 20:24:06 -0800, Mark Nottingham wrote: > > +1 > > Welcome to the club :) > > > On Feb 2, 2005, at 10:29 AM, Robert Sayre wrote: > > > > > 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 its detractors still oppose it. > > Design by committee at its worst. > > > > Remove atom:info > > ------------------- > > Back when we were arguing about IETF vs. W3C, mnot said "in the IETF, > > it's easier to shut down a solo raving loony." In the threads on > > atom:info, it seems I am playing the role of solo raving loony. So, > > let's have the process take over. > > > > Robert Sayre > > > > > > > > -- > Mark Nottingham http://www.mnot.net/ > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 00:53:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08066 for ; Fri, 4 Feb 2005 00:53:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145gEQN095832; Thu, 3 Feb 2005 21:42:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145gELl095831; Thu, 3 Feb 2005 21:42:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145gDE5095823 for ; Thu, 3 Feb 2005 21:42:13 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so593586rng for ; Thu, 03 Feb 2005 21:42:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=r3xumZs8YRViqvgElvPPyXUUCm7LJfcZ4B+BTJGqElCOqUBFcsT8YuMWwKi3AqNmCyrHV0Y2AvTq2IbBKjZ6ham0O/3aRQMtZjhNOwvdxyydWMTWQNTtC+qVAJP+0hEHirU0ZPqQ1MeNkwvbS+AJYBlcUR+hVYCiKs7b2S31GQ4= Received: by 10.38.125.29 with SMTP id x29mr20528rnc; Thu, 03 Feb 2005 21:42:07 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 21:42:07 -0800 (PST) Message-ID: <2bcdc7c4050203214259917c99@mail.gmail.com> Date: Thu, 3 Feb 2005 21:42:07 -0800 From: James Snell Reply-To: James Snell To: Tim Bray Subject: Re: Organization Use Cases (was: Re: Format spec vs Protocol spec) Cc: Robert Sayre , Atom Syntax , Walter Underwood In-Reply-To: <265086a959e5bf339cecb7adb98a8f76@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41FFEF0D.1090200@gmx.de> <420125F2.7080402@franklinmint.fm> <420134D3.2090400@franklinmint.fm> <265086a959e5bf339cecb7adb98a8f76@sun.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Potential solutions that occur to me: > > 1. Ignore the problem > 2. PaceEntriesElement could handle this > 3. PaceFeedRecursive could handle this > 4. PaceAtomHeadInEntry could handle this > 5. PaceAggregationDocument could handle this > > I honestly can't say which I prefer. Would anyone like to try to put > together examples of the solution in #2 through #5 so that we can > consider the alternatives? > 6. Handle the problem in a non-core extension. The core Atom syntax does not have to deal with all these cases as long as it does not interfere with someones ability to deal with cases later on. Get version one out the door. Get folks to start implementing it. Start writing up extensions. Get folks to implement those extensions. Figure out which extensions are Really Useful. Add those Really Useful Extensions to the core later. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 00:55:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08264 for ; Fri, 4 Feb 2005 00:55:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145kU3W096116; Thu, 3 Feb 2005 21:46:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145kUq1096115; Thu, 3 Feb 2005 21:46:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145kNgd096105 for ; Thu, 3 Feb 2005 21:46:23 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C1C6E51A12; Fri, 4 Feb 2005 00:46:22 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Sam Ruby X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: PaceProfile - new Date: Thu, 3 Feb 2005 21:46:20 -0800 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm. [[[ #pragma section-numbers off == Abstract == Rearrange the format draft to allow @version (or a replacement attribute, @profile) to identify the kinds and cardinality of metadata that are required in the feed. Also, provide better separation between Atom-defined elements that are containers and Atom elements that are metadata. == Status == New. == Rationale == There are a number of use cases for Atom (e.g., blogs, news, archiving, stock quotes, systems monitoring); each has potentially different requirements for the presences of certain kinds of metadata. To cater to these use cases, and allow implementations to make assumptions about feed content when presenting it, we need to identify the *profile* of metadata that a feed can be expected to contain. Furthermore, we need to ship at least one profile with the spec. Right now, it's embedded in the schema of what metadata elements are required; it would be better to explicitly call it out. == Proposal == 1) Change the organisation of the document to this rough outline; 1. Introduction 1.1 Editorial Notes 1.2 Example 1.3 Conformance 1.4 Notational Conventions 2. Atom Documents 2.1 Atom Feed Documents 2.2 Atom Entry Documents 3. Atom Container Elements 3.1 The "atom:feed" Element 3.2 The "atom:head" Element 3.2.1 The "atom:profile" Attribute 3.3 The "atom:entry" Element 3.3.1 The "atom:profile" Attribute 4. Atom Core Metadata Elements 4.1 The "atom:title" Element 4.2 The "atom:id" Element 4.3 The "atom:link" Element 4.4 The "atom:updated" Element 4.5 The "atom:published" Element 4.6 The "atom:author" Element 4.7 The "atom:contributor" Element 4.8 The "atom:host" Element 4.9 The "atom:copyright" Element 4.10 The "atom:category" Element 4.11 The "atom:summary" Element 4.12 The "atom:content" Element 4.13 The "atom:introspection" Element 4.14 The "atom:post" Element 4.15 The "atom:edit" Element 4.16 The "atom:tagline" Element 4.17 The "atom:generator" Element 4.18 The "atom:info" Element 5. Common Atom Constructs 5.1 Text Constructs 3.2 Person Constructs 3.3 Date Constructs 3.4 Service Constructs 6. Atom Profiles 6.1 The Atom Syndication Profile 6.2 The Atom Archiving Profile 7. Managing Feed State 8. Securing Atom Documents 8.1 Digital Signatures 8.2 Encryption 9. Embedding Atom in Other Formats 10. Extending Atom 11. IANA Considerations 11.1 Registry of Link Relations 12. Security Considerations This effectively positions Atom Documents as *containers* of bags of metadata, and the children of those containers as *metadata*; the only place where we constrain what kind of metadata is required in the feed, and how many times each one can appear, is in the profile definition (section 6 here). This flexibility point allows new arrangements of metadata to be accommodated as new profiles, while still providing default profiles with the spec so that we ship something interoperable. It also means that the only reason to change the namespace for atom:feed, atom:head and atom:entry is if their semantics change; likewise, the only reason to change the namespace for one of the metadata elements is if its semantics changes. == Impacts == Changes the layout of the specification and the ability to define new extensions and profiles; does not affect current implementations at all, with the possible exception of changing @version to @profile (see below). == Notes == I'm more than happy to submit a personal draft to the WG to show more detail of what this would look like. I'm not stuck on the term "profile"; in fact, I'm happy to ditch @profile as long as the semantics of @version are changed to this. Note that a profile DOES NOT preclude the addition of more metadata; it only states what metadata is required to be there. So, you can extend a profile, you just can't go below its bar. ---- CategoryProposals ]]] -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 01:03:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08837 for ; Fri, 4 Feb 2005 01:03:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145uFoN096830; Thu, 3 Feb 2005 21:56:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j145uFQs096829; Thu, 3 Feb 2005 21:56:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j145uEfV096819 for ; Thu, 3 Feb 2005 21:56:15 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwwRv-0005sw-1Y; Fri, 04 Feb 2005 05:56:11 +0000 Message-ID: <42030E77.5040707@franklinmint.fm> Date: Fri, 04 Feb 2005 00:56:07 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snell CC: bob@wyman.us, Tim Bray , Atom Syntax Subject: Re: On organization and abstraction References: <200502040412.CNG98291@ms8.netsolmail.com> <2bcdc7c405020321371d53a409@mail.gmail.com> In-Reply-To: <2bcdc7c405020321371d53a409@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: > On Thu, 3 Feb 2005 23:08:43 -0500, Bob Wyman wrote: > >> 4. Massive changes need to be made to the specification when we >>don't have a great deal of time left before we're supposed to be doing a >>"Last Call." This is dangerous. >> > > +1. Big +1. > I really regret writing down the religion that format-05 seems to embody. Take a look at PaceEntriesElement. It does not propose a "massive change". It's just *shorter*. Some quotes from format-05: "Atom is an XML-based document format which describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title." "The "atom:feed" element is the document (i.e., top-level) element of an Atom Feed Document, acting as a container for metadata and data associated with the feed" "The "atom:entry" element represents an individual entry." I really must find out more about this theology that allows one to divine the precise nature of lists, data, metadata, items, containers, and representations. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 01:30:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10731 for ; Fri, 4 Feb 2005 01:30:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146805m000107; Thu, 3 Feb 2005 22:08:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14680O5000106; Thu, 3 Feb 2005 22:08:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1467xuA099964 for ; Thu, 3 Feb 2005 22:08:00 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so379696rne for ; Thu, 03 Feb 2005 22:07:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=VKfUJgd2GbsRUFQ6LK4PtdtstP8fYZg62wkpnt8xyOIsc1KBOlDd0ZjABTSD52NQ24K7dmbV2cS4UBdPRshiNhbO7gAtvy4QuqoyNyiPHUpczzpbT45Ru8sPqai2mPRbwNwsW9xivsAc4Xv3JyaZq+5rIyE/w5l402wpPLZLbQw= Received: by 10.38.218.39 with SMTP id q39mr23675rng; Thu, 03 Feb 2005 22:07:54 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 22:07:54 -0800 (PST) Message-ID: <2bcdc7c40502032207357c824@mail.gmail.com> Date: Thu, 3 Feb 2005 22:07:54 -0800 From: James Snell Reply-To: James Snell To: Atom Syntax Subject: New Pace: PaceAggregationInSeparateSpec Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Figured I would formalize what I've been evangelizing the past couple of days. http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec == Abstract == Defer the definition of solutions for aggregated feeds to a separate Internet-Draft that is not a part of the Atom core syntax specification. == Status == Proposed (by [JamesSnell]) == Rationale == Aggregated feeds, while important, are currently not supported by the existing RSS mechanisms and are relatively rare in comparison to their single feed cousins. Given the guidelines for proposals set forth in this Wiki, this alone would justify moving the aggregation stuff off to a separate document, at least for now. * The 80/20 rule: If a feature will only be used by a small number of people, and will create extra work and headaches for everyone else, it probably doesn't belong in the core spec. * Pick stuff that's already been proven to work and be interoperable, and writing it down in a clean, clear way * Keep it simple: The simplest thing that can possibly work tends to be preferred over more complex solutions. I absolutely acknowledge that there are a subset of folks for whom aggregated feeds are very important. But this is a subset. Let that subset document their ideas in a separate Internet-Draft; let them implement those ideas and build momentum for them; then let us later come back later and discuss the merits of merging those ideas into the core. == Proposal == (see abstract) == Impacts == Defers PageAggregationDocument and PageFeedRecursive to a separate Internet-Draft * Lets Atom 1.0 get out the door faster. * Lets folks gain valuable implementation experience before committing to major changes to the Atom core spec to support what is currently an edge case * Keeps the Atom core simple == Notes == -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 01:36:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11364 for ; Fri, 4 Feb 2005 01:36:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146RDGH006049; Thu, 3 Feb 2005 22:27:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j146RDY2006048; Thu, 3 Feb 2005 22:27:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146R8we005889 for ; Thu, 3 Feb 2005 22:27:08 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:50114 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228747AbVBDG0u (ORCPT ); Fri, 4 Feb 2005 08:26:50 +0200 In-Reply-To: <87brb14591.fsf@nwalsh.com> References: <87acql71po.fsf@nwalsh.com> <66dba0a7b593af288d3b93a968036631@sun.com> <87brb14591.fsf@nwalsh.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78883e423eae70913855de6d7cd84967@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: RELAX NG Grammar question Date: Fri, 4 Feb 2005 08:26:48 +0200 To: Norman Walsh X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 4, 2005, at 01:02, Norman Walsh wrote: > | As for the XHTML thing, I think this is going to happen all the time > (foreign > | markup in embedded XHTML) and I don't think we should try to get in > the way. > | However, I just now tried to think of some spec language to express > this and > | came up empty. -Tim > > I think the spec language is fine > > If the value of "type" is "XHTML", the content of the Text construct > MAY contain child elements. The content SHOULD be XHTML text and > markup that could validly appear directly within an xhtml:div > element. Depending on what W3C DTD you choose to read, you could put MathML or even SVG there, which is fine, IMO, because I don't think it makes sense to exclude well-known vocabularies that you could legitimately serve embedded in application/xhtml+xml. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Fri Feb 4 01:38:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11427 for ; Fri, 4 Feb 2005 01:38:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146R3wH005968; Thu, 3 Feb 2005 22:27:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j146R3n2005967; Thu, 3 Feb 2005 22:27:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146Qwan005933 for ; Thu, 3 Feb 2005 22:26:59 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so382581rne for ; Thu, 03 Feb 2005 22:26:58 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=BpUMfcXBnk5qDYLmYs7+b6ZSpEgJErof2FKNCz2CSS0S4h7oPWaIe9OHh2CVp5/qrxSReiyqfg2QO4ddnRnHr6PxORwhLtt/vcPFMBVfMtZZuTYUsRKo6wALme6zjyeUNM3KqfhJcSvUcgfkqjpTzNxAkIiljhWpOOntKHCUs8A= Received: by 10.39.1.24 with SMTP id d24mr37480rni; Thu, 03 Feb 2005 22:20:18 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 22:20:18 -0800 (PST) Message-ID: <2bcdc7c405020322203ca7fc57@mail.gmail.com> Date: Thu, 3 Feb 2005 22:20:18 -0800 From: James Snell Reply-To: James Snell To: Mark Nottingham Subject: Re: PaceProfile - new Cc: Atom Syntax , Sam Ruby In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I like the fundamental idea here, but there are a couple of issues: 1. There needs to be a clear description of what a profile is. 2. There needs to be a clear description of how profiles are defined 3. There needs to be a clear description of how profiles are handled The first is simple enough. The second is a bit more difficult. I would imagine the process would be that a profile needs to be described by some form of document (perhaps an Internet-Draft) but what process is required beyond that? An IANA registry of profile identifiers? The third deals with a very specific question: what should a client do with a feed using a profile that it doesn't understand? While this has the potential to cause a significant update to the current document (something I'm hesitant to support), the current @version is meaningless as is and really should be drastically improved. Something like the following would be far more useful. ... ... ... ...etc Just for consideration, a possible alternative approach would be an attribute that lists multiple profiles supported by a feed. However, this is obviously more complex and therefore less likely to be useful. ... (p.s. the assumption in the above examples is that the values of the @profile and @profiles attributes are meaningfully defined and registered via IANA, like link @rel values) On Thu, 3 Feb 2005 21:46:20 -0800, Mark Nottingham wrote: > > I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm. > > [[[ > #pragma section-numbers off > > == Abstract == > > Rearrange the format draft to allow @version (or a replacement > attribute, @profile) to identify the kinds and cardinality of metadata > that are required in the feed. Also, provide better separation between > Atom-defined elements that are containers and Atom elements that are > metadata. > > == Status == > > New. > > == Rationale == > > There are a number of use cases for Atom (e.g., blogs, news, archiving, > stock quotes, systems monitoring); each has potentially different > requirements for the presences of certain kinds of metadata. To cater > to these use cases, and allow implementations to make assumptions about > feed content when presenting it, we need to identify the *profile* of > metadata that a feed can be expected to contain. > > Furthermore, we need to ship at least one profile with the spec. Right > now, it's embedded in the schema of what metadata elements are > required; it would be better to explicitly call it out. > > == Proposal == > > 1) Change the organisation of the document to this rough outline; > > 1. Introduction > 1.1 Editorial Notes > 1.2 Example > 1.3 Conformance > 1.4 Notational Conventions > > 2. Atom Documents > 2.1 Atom Feed Documents > 2.2 Atom Entry Documents > > 3. Atom Container Elements > 3.1 The "atom:feed" Element > 3.2 The "atom:head" Element > 3.2.1 The "atom:profile" Attribute > 3.3 The "atom:entry" Element > 3.3.1 The "atom:profile" Attribute > > 4. Atom Core Metadata Elements > 4.1 The "atom:title" Element > 4.2 The "atom:id" Element > 4.3 The "atom:link" Element > 4.4 The "atom:updated" Element > 4.5 The "atom:published" Element > 4.6 The "atom:author" Element > 4.7 The "atom:contributor" Element > 4.8 The "atom:host" Element > 4.9 The "atom:copyright" Element > 4.10 The "atom:category" Element > 4.11 The "atom:summary" Element > 4.12 The "atom:content" Element > 4.13 The "atom:introspection" Element > 4.14 The "atom:post" Element > 4.15 The "atom:edit" Element > 4.16 The "atom:tagline" Element > 4.17 The "atom:generator" Element > 4.18 The "atom:info" Element > > 5. Common Atom Constructs > 5.1 Text Constructs > 3.2 Person Constructs > 3.3 Date Constructs > 3.4 Service Constructs > > 6. Atom Profiles > 6.1 The Atom Syndication Profile > 6.2 The Atom Archiving Profile > > 7. Managing Feed State > > 8. Securing Atom Documents > 8.1 Digital Signatures > 8.2 Encryption > > 9. Embedding Atom in Other Formats > > 10. Extending Atom > > 11. IANA Considerations > 11.1 Registry of Link Relations > > 12. Security Considerations > > This effectively positions Atom Documents as *containers* of bags of > metadata, and the children of those containers as *metadata*; the only > place where we constrain what kind of metadata is required in the feed, > and how many times each one can appear, is in the profile definition > (section 6 here). > > This flexibility point allows new arrangements of metadata to be > accommodated as new profiles, while still providing default profiles > with the spec so that we ship something interoperable. > > It also means that the only reason to change the namespace for > atom:feed, atom:head and atom:entry is if their semantics change; > likewise, the only reason to change the namespace for one of the > metadata elements is if its semantics changes. > > == Impacts == > > Changes the layout of the specification and the ability to define new > extensions and profiles; does not affect current implementations at > all, with the possible exception of changing @version to @profile (see > below). > > == Notes == > > I'm more than happy to submit a personal draft to the WG to show more > detail of what this would look like. > > I'm not stuck on the term "profile"; in fact, I'm happy to ditch > @profile as long as the semantics of @version are changed to this. > > Note that a profile DOES NOT preclude the addition of more metadata; it > only states what metadata is required to be there. So, you can extend a > profile, you just can't go below its bar. > > ---- > > CategoryProposals > > ]]] > -- > Mark Nottingham http://www.mnot.net/ > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 01:49:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA12060 for ; Fri, 4 Feb 2005 01:49:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146dxo8013374; Thu, 3 Feb 2005 22:39:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j146dx1q013373; Thu, 3 Feb 2005 22:39:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j146dw54013306 for ; Thu, 3 Feb 2005 22:39:59 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050204063953016004deqae>; Fri, 4 Feb 2005 06:39:53 +0000 Date: Thu, 3 Feb 2005 23:39:51 -0700 Subject: Re: New Pace: PaceAggregationInSeparateSpec Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <2bcdc7c40502032207357c824@mail.gmail.com> Message-Id: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote: > Figured I would formalize what I've been evangelizing the past couple > of days. > > http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec > The only reason why I'm not in favor of this (in fact, it occurred to me a little before I saw this message) is that leaving things as they are and deferring deciding how to handle aggregation would irreversibly enshrine HeadInEntry into the format, which all of the current organizational proposals are trying to replace. Deciding to defer==deciding to do it HeadInEntry style. From owner-atom-syntax@mail.imc.org Fri Feb 4 02:34:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28920 for ; Fri, 4 Feb 2005 02:34:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147RN94031529; Thu, 3 Feb 2005 23:27:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147RNu9031528; Thu, 3 Feb 2005 23:27:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147REbZ031466 for ; Thu, 3 Feb 2005 23:27:18 -0800 (PST) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j147REVu011729 for ; Fri, 4 Feb 2005 00:27:14 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBD003EVM1D7Q@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 00:27:13 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBD005NFM1CUN@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 00:27:13 -0700 (MST) Date: Thu, 03 Feb 2005 23:27:21 -0800 From: Tim Bray Subject: Re: PaceExtendingAtom In-reply-to: <63e2637b4f5cde830343778bb9722713@mnot.net> To: Mark Nottingham Cc: Atom Syntax Message-id: <55bebef8e933fd963aa8653cc0082765@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <63e2637b4f5cde830343778bb9722713@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote: >> This specification describes Atom's XML markup vocabulary. >> Markup from >> other vocabularies ("foreign markup") can be used in Atom in >> a variety of >> ways. Text Constructs may contain foreign markup which SHOULD >> be HTML or >> XHTML. > > What does this statement add? Why is HTML or XHTML normatively > preferred over text, MathML, or any other vocabulary? It's not preferred over text, you can say type='TEXT', but since this is a *text* construct and quite likely to be presented in rows & columns (title, author, etc) simpler is better, so I'd think the SHOULD is sensible here. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 02:35:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29066 for ; Fri, 4 Feb 2005 02:35:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147SYll031827; Thu, 3 Feb 2005 23:28:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147SYbU031826; Thu, 3 Feb 2005 23:28:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147SX7S031790 for ; Thu, 3 Feb 2005 23:28:33 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020407030801200fvc45e>; Fri, 4 Feb 2005 07:03:08 +0000 Date: Fri, 4 Feb 2005 00:03:06 -0700 Subject: Re: On organization and abstraction Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200502040412.CNG98291@ms8.netsolmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, February 3, 2005, at 09:08 PM, Bob Wyman wrote: > I see two non-compelling benefits to PaceAggregationDocument over > PaceHeadInEntry: > 1. In the case where a feed will contain more than one entry from a > "foreign" feed, you only have to include the atom:head data once. Thus, > there would be some increase in efficiency of encoding... However, as > I've > pointed out on numerous occasions, this is a rare case. Typically, at > PubSub, we DO NOT see many cases where atom:head information is > repeated in > a single instance of a feed. In the past few days, I've been reading people talking about different ways emerging for people to combine or divide the content of their own feeds based on what's going to end up in our element and by other methods. (See http://www.mezzoblue.com/archives/2005/02/03/information_/index.php). This kind of thinking could very well point the way to the emergence of more feeds being aggregated from a small number of sources. Time will tell. > 2. It is easier to see how one would sign an aggregated entry since > you don't muck with the contents of entry by inserting the > HeadInEntry. This > problem, however, would be solved by canonicalization rules that said > that > you should remove HeadInEntry before processing signatures, or, rules > that > said that you had to insert HeadInEntry before signing anything, or > filter > rules that allowed one to flag HeadInEntry as not part of the signed > content. (i.e. alternative solutions exist...) When you remove HeadInEntry, do you remove from the start of the tag to the end of the tag, or do you also take out the newline after the tag...? We'd have to be certain we defined the process precisely and that people followed it precisely. The benefit of avoiding that complexity may be a little greater than it appears at first blush. > But, there are tremendous problems with the proposal: > 1. It looks like I can't intersperse "native" entries with > aggregated entries. This is a nuisance. I would like to see people > insert > entries with "HeadInEntry" when they copy something from another feed > into > their own feed. PaceAggregationDocument says that your feed must have > either > "native" entries or "foreign" entries, but it can't have both. This > seems > like an unnecessary constraint. You could always have a feed in the aggregation for the "native" entries. But you do have a point--the thing that would be more difficult would be to occasionally import external content into a feed that is not always an aggregation--you'd either have to temporarily become an aggregation, refer to it rather than importing it, or forget it. Out of curiosity though, how common is it to import entries wholesale from external sources as opposed to referring to them? > 2. As mentioned before, the introduction of a new level of > abstraction (i.e. aggregation) is likely to scare off a good > proportion of > the aggregator developers. Current aggregators don't have the concept > of > "aggregation" in them. Thus, new design and new architecture will be > required to address this Pace. On the other hand, staying with > HeadInEntry > is much more gentle on the existing systems and thus much more likely > to be > useful in the field. Current aggregators don't have the concept of HeadInEntry either. With HeadInEntry, it's easier because you don't have to deal with one more level of hierarchy--if you don't know about HeadInEntry and just ignore it, you can still function. However, that leads to erroneously attributing an entry to the wrong feed. To get it right, aggregators are going to have to understand SOMETHING new. The containment in an aggregation document would be more intuitively obvious in meaning than seeing a head in an entry and figuring out that it was the head from the feed that used to surround the entry. > 4. Massive changes need to be made to the specification when we > don't have a great deal of time left before we're supposed to be doing > a > "Last Call." This is dangerous. If we don't want to reorganize the spec to do this, we can create PaceAggregationDocument2 which does it more simply by making only four changes: 1) add an aggregation element 2) state that it requires an atom:head 3) state that it can contain any number of atom:feeds 4) state that it can be the document element From owner-atom-syntax@mail.imc.org Fri Feb 4 02:38:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29244 for ; Fri, 4 Feb 2005 02:38:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147QHNd031150; Thu, 3 Feb 2005 23:26:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147QH1r031149; Thu, 3 Feb 2005 23:26:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147QEmu030965 for ; Thu, 3 Feb 2005 23:26:15 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 20:08:57 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 18:08:10 +1100 Subject: Re: New Pace: PaceAggregationInSeparateSpec From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c40502032207357c824@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 5:07 PM, "James Snell" wrote: > Defer the definition of solutions for aggregated feeds to a separate > Internet-Draft that is not a part of the Atom core syntax > specification. +1 From owner-atom-syntax@mail.imc.org Fri Feb 4 02:42:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29585 for ; Fri, 4 Feb 2005 02:42:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147YKD4033848; Thu, 3 Feb 2005 23:34:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147YKL7033847; Thu, 3 Feb 2005 23:34:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147YIWA033833 for ; Thu, 3 Feb 2005 23:34:19 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 20:00:46 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 17:59:59 +1100 Subject: Re: CAP over Atom (PubSub "Common Alerting Protocol" Earthquake Feeds...) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c405020321176d17a66d@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> Because CAP is an XML format, we're using atom:content elements with >> type="text/xml". In order to ensure that there is something for aggregators >> to display if they don't understand CAP, we're generating atom:summary >> elements that contain a textual summary of the CAP message which is in the >> atom:content. My hope is that aggregator developers will commonly implement >> a pattern of displaying the atom:summary rather then the atom:content in >> cases where they don't understand the XML type of the content element. +1 From owner-atom-syntax@mail.imc.org Fri Feb 4 02:45:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29702 for ; Fri, 4 Feb 2005 02:45:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147cRuR035302; Thu, 3 Feb 2005 23:38:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147cR7B035301; Thu, 3 Feb 2005 23:38:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147cQRZ035292 for ; Thu, 3 Feb 2005 23:38:27 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwxfV-0006P5-EW; Fri, 04 Feb 2005 07:14:17 +0000 Message-ID: <420320C6.8030504@franklinmint.fm> Date: Fri, 04 Feb 2005 02:14:14 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: New Pace: PaceAggregationInSeparateSpec References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> In-Reply-To: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > leaving things as they are > and deferring deciding how to handle aggregation would irreversibly > enshrine HeadInEntry into the format, which all of the current > organizational proposals are trying to replace. That's right. Besides, HeadInEntry is trivial to do as an extension, so there's no reason to leave it in. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 02:52:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00184 for ; Fri, 4 Feb 2005 02:52:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147kA7s038092; Thu, 3 Feb 2005 23:46:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147kA0K038091; Thu, 3 Feb 2005 23:46:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147k7UL038071 for ; Thu, 3 Feb 2005 23:46:09 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 20:46:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 18:46:04 +1100 Subject: Re: Feed State [was: Work Queue Rotation #16] From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <1b107d3ab76c67950c13835cd8365f3f@mnot.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 4:03 PM, "Mark Nottingham" wrote: > This is now PaceNoFeedState; > http://www.intertwingly.net/wiki/pie/PaceNoFeedState +1 e. From owner-atom-syntax@mail.imc.org Fri Feb 4 02:58:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00498 for ; Fri, 4 Feb 2005 02:58:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147m802038842; Thu, 3 Feb 2005 23:48:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147m8tw038841; Thu, 3 Feb 2005 23:48:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.207]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147m7bc038812 for ; Thu, 3 Feb 2005 23:48:07 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so395078rne for ; Thu, 03 Feb 2005 23:48:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=T2AjQxgCQl19IGvstPiodauk31stgmWn3K+CjDlffRBDFbiIh7WRRVk4qacEgEQC1e1LuKQueB7oSt0jfJ0gXl90FihfGG5F88th321OD1gRbME5YNWWtpUQbMqnef4WqDaupORr779TE59+tVO3iFBiy5agH+uUsMs8bHQ6q88= Received: by 10.38.71.29 with SMTP id t29mr80667rna; Thu, 03 Feb 2005 23:48:04 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 23:48:04 -0800 (PST) Message-ID: <2bcdc7c405020323486611154a@mail.gmail.com> Date: Thu, 3 Feb 2005 23:48:04 -0800 From: James Snell Reply-To: James Snell To: Robert Sayre Subject: Re: New Pace: PaceAggregationInSeparateSpec Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <420320C6.8030504@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 04 Feb 2005 02:14:14 -0500, Robert Sayre wrote: > > Antone Roundy wrote: > > > > leaving things as they are > > and deferring deciding how to handle aggregation would irreversibly > > enshrine HeadInEntry into the format, which all of the current > > organizational proposals are trying to replace. > > That's right. Besides, HeadInEntry is trivial to do as an extension, so > there's no reason to leave it in. > I agree with this so long as there is a core mechanism that allows a standalone entry to identify the feed to which it belongs. That mechanism does not have to be atom:head, but it does need to be part of the core. > Robert Sayre > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 03:00:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00645 for ; Fri, 4 Feb 2005 03:00:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147pYOt040171; Thu, 3 Feb 2005 23:51:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147pYn9040166; Thu, 3 Feb 2005 23:51:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147pX7P040149 for ; Thu, 3 Feb 2005 23:51:33 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CwyFX-0006g1-Jw; Fri, 04 Feb 2005 07:51:31 +0000 Message-ID: <42032980.7040400@franklinmint.fm> Date: Fri, 04 Feb 2005 02:51:28 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snell CC: Antone Roundy , atom-syntax@imc.org Subject: Re: New Pace: PaceAggregationInSeparateSpec References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> <2bcdc7c405020323486611154a@mail.gmail.com> In-Reply-To: <2bcdc7c405020323486611154a@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: >> >>That's right. Besides, HeadInEntry is trivial to do as an extension, so >>there's no reason to leave it in. >> > > > I agree with this so long as there is a core mechanism that allows a > standalone entry to identify the feed to which it belongs. That > mechanism does not have to be atom:head, but it does need to be part > of the core. Why? Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 03:03:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00821 for ; Fri, 4 Feb 2005 03:03:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147u957041942; Thu, 3 Feb 2005 23:56:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j147u9F1041941; Thu, 3 Feb 2005 23:56:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j147u8rL041903 for ; Thu, 3 Feb 2005 23:56:09 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so396336rne for ; Thu, 03 Feb 2005 23:56:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lLuv/P+3YoteGFqRKgGbOAdxHGwWPVEygrC9r9u+086eNj6vKTN6KPYqydg70XauPgjNw94zmnUMVwrnKL6V0FtXiZUMKr9caU8lj0zamZuW1TUIXh1wmezyo9IgZmUDVNdF7FM/fzIKrzfUYxBph8PGUl5FmRAw77NudIuSIwA= Received: by 10.38.149.10 with SMTP id w10mr61842rnd; Thu, 03 Feb 2005 22:56:03 -0800 (PST) Received: by 10.38.72.20 with HTTP; Thu, 3 Feb 2005 22:56:03 -0800 (PST) Message-ID: <2bcdc7c40502032256671edaf0@mail.gmail.com> Date: Thu, 3 Feb 2005 22:56:03 -0800 From: James Snell Reply-To: James Snell To: Antone Roundy Subject: Re: New Pace: PaceAggregationInSeparateSpec Cc: atom-syntax@imc.org In-Reply-To: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c40502032207357c824@mail.gmail.com> <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 23:39:51 -0700, Antone Roundy wrote: > > On Thursday, February 3, 2005, at 11:07 PM, James Snell wrote: > > Figured I would formalize what I've been evangelizing the past couple > > of days. > > > > http://www.intertwingly.net/wiki/pie/PaceAggregationInSeparateSpec > > > The only reason why I'm not in favor of this (in fact, it occurred to > me a little before I saw this message) is that leaving things as they > are and deferring deciding how to handle aggregation would irreversibly > enshrine HeadInEntry into the format, which all of the current > organizational proposals are trying to replace. Deciding to > defer==deciding to do it HeadInEntry style. > > I don't agree. HeadInEntry can be debated seprately on its own merits (or lack thereof). For Atom Entry Documents, there MUST be a way of providing some set of Feed metadata identifying a feed to which this entry belongs or is related. HeadInEntry accomplishes that goal, but is not the only way to achieve it. If HeadInEntry's primary motivator is to act as a support for aggregated feeds, then it to is affected by the PaceAggregationInSeparateSpec proposal and should likely also be removed from the core and deferred so long as the requirement stated above is still met (somehow) For example, it would be possible to achieve the linking requirement for entry documents using the link element rather than head, which could allow us to remove HeadInEntry. This, obviously, is not the only solution, but the point remains the same. If HeadInEntry doesn't make sense, PaceAggregationInSeparateSpec does nothing to require that it stay in the core spec. -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 03:11:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01355 for ; Fri, 4 Feb 2005 03:11:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1485TAe045275; Fri, 4 Feb 2005 00:05:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1485T1V045274; Fri, 4 Feb 2005 00:05:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1485SBB045206 for ; Fri, 4 Feb 2005 00:05:28 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so397952rne for ; Fri, 04 Feb 2005 00:05:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Tn7wwmRE9z6HmHifaV7mfHtteYTjHA+VPJo3FD17nmTdioIL32IspNeO75iBuLGArh8mOOVNDP0DZGYgox829RdVazNAps6yyCh1FFb3jZJS0IOJy24IW4sS3u5/37XEp7NdheUVuReNGv0U9SEXoJOD9TiDqhqrAA8QRgu/eJE= Received: by 10.38.218.39 with SMTP id q39mr74888rng; Fri, 04 Feb 2005 00:05:20 -0800 (PST) Received: by 10.38.72.20 with HTTP; Fri, 4 Feb 2005 00:05:20 -0800 (PST) Message-ID: <2bcdc7c405020400052badd70e@mail.gmail.com> Date: Fri, 4 Feb 2005 00:05:20 -0800 From: James Snell Reply-To: James Snell To: Robert Sayre Subject: Re: New Pace: PaceAggregationInSeparateSpec Cc: Antone Roundy , atom-syntax@imc.org In-Reply-To: <42032980.7040400@franklinmint.fm> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> <2bcdc7c405020323486611154a@mail.gmail.com> <42032980.7040400@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Fri, 04 Feb 2005 02:51:28 -0500, Robert Sayre wrote: > James Snell wrote: > >> > >>That's right. Besides, HeadInEntry is trivial to do as an extension, so > >>there's no reason to leave it in. > >> > > > > > > I agree with this so long as there is a core mechanism that allows a > > standalone entry to identify the feed to which it belongs. That > > mechanism does not have to be atom:head, but it does need to be part > > of the core. > > Why? > As soon as I posted I knew you were going to come back and ask that :-) As defined by the spec, entries exist either independently or within the context of a feed. The state of being associated with a feed is a part of the core metadata about an entry given this definition. In standalone entries, absent HeadInEntry, there is no mechanism of expressing whether or not the entry is associated with a feed. The only assumption that can be made in that case, is that a standalone entry is not associated with any feed. As examples, the Atom-XMPP-Notify and Atom-HTTP-Notify proposals both illustrate cases where this assumption is not acceptable. Granted, however, both of these proposals could just as easily use some shared non-core extension element to identify the parent feed. Bottom line: In my opinion, the parent feed is just as core to the entries metadata as is the date it was updated or any of the other core elements. It *could* be defined as an extension, but I feel it is better handled in the core. > Robert Sayre > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 04:52:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07489 for ; Fri, 4 Feb 2005 04:52:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j148Oxe8052406; Fri, 4 Feb 2005 00:24:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j148Oxo0052405; Fri, 4 Feb 2005 00:24:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j148OwP5052349 for ; Fri, 4 Feb 2005 00:24:58 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 41856 invoked by uid 17064); 4 Feb 2005 08:24:50 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.8.16]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Feb 2005 08:24:50 -0000 In-Reply-To: <2bcdc7c405020400052badd70e@mail.gmail.com> References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> <2bcdc7c405020323486611154a@mail.gmail.com> <42032980.7040400@franklinmint.fm> <2bcdc7c405020400052badd70e@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3fa72be3956ca366d82c0a15ea02d698@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Robert Sayre , Antone Roundy , atom-syntax@imc.org From: Henry Story Subject: Re: New Pace: PaceAggregationInSeparateSpec Date: Fri, 4 Feb 2005 09:24:24 +0100 To: James Snell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 09:05, James Snell wrote: > Bottom line: In my opinion, the parent feed is just as core to the > entries metadata as is the date it was updated or any of the other > core elements. It *could* be defined as an extension, but I feel it > is better handled in the core. I have heard interesting arguments "It's all about the Entries, stupid!" that made the opposite assessment: namely that the entries are what is important, and that what feed an Entry is part of, is a accident of life. The idea there is that Entries are the stand alone entities. They can be made to be part of any feed whatsoever. A feed in this conceptualization, is a little like a search engine result listing where the pages they refer to are like entries (notice that search engine results pages are just a type of web page too). Which feed your entry appears in will depend very much on the type of query the user of the search engine made. Of course if an entry has a tag such as "origin" (which used to be on the table) then the entry it points to would be part of the metadata of the entry and so be a legitimate way of creating special selection of entries. Henry Story From owner-atom-syntax@mail.imc.org Fri Feb 4 05:03:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08474 for ; Fri, 4 Feb 2005 05:03:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149rUOn080944; Fri, 4 Feb 2005 01:53:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j149rUHI080943; Fri, 4 Feb 2005 01:53:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j149rTgh080899 for ; Fri, 4 Feb 2005 01:53:29 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 98834 messnum 2830438 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 4 Feb 2005 09:53:23 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail06.svc.cra.dublin.eircom.net (qp 98834) with SMTP; 4 Feb 2005 09:53:23 -0000 Message-ID: <4203460F.7010901@dehora.net> Date: Fri, 04 Feb 2005 09:53:19 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceProfile - new References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> In-Reply-To: <2bcdc7c405020322203ca7fc57@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: > I like the fundamental idea here, but there are a couple of issues: > > 1. There needs to be a clear description of what a profile is. > 2. There needs to be a clear description of how profiles are defined > 3. There needs to be a clear description of how profiles are handled > > [...] > > While this has the potential to cause a significant update to the > current document (something I'm hesitant to support), the current > @version is meaningless as is and really should be drastically > improved. Something like the following would be far more useful. > > ... > ... > ... > ...etc I'm -1 on this pace. One concern I have is that I don't want to see feed data constrained according to usecases (ie system monitoring); that makes the data less useful and goes down the route of publishers telling clients how to write their applications or making assumptions on how data will be processed downstream. While I believe that claiming Atom is a container for metadata is good, I doubt that profiling represents a more flexible approach - it moves us away from agents coordinating together to agents enforcing policy on one another via a profiling mechanism. The place to put such constraints is on the range and domain of the metadata properties or in themed extensions - RDF clearly gets this right as do RSS1.0 modules. I have doubts about profiles will work out as they seem to range over the entire feed rather than an item of metadata. As for @version being meaningless; it's not. It's sufficient for someone to swap in a code handler by switching on type. It might not have any forward or back compatible semantics but it is does signify wrt other versions. The @profile (as presented above) has no more or less meaning that @version. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 4 05:03:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08529 for ; Fri, 4 Feb 2005 05:03:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149us4U082197; Fri, 4 Feb 2005 01:56:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j149usMF082196; Fri, 4 Feb 2005 01:56:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149urJv082183 for ; Fri, 4 Feb 2005 01:56:53 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 22:57:39 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 20:56:51 +1100 Subject: Re: New Pace: PaceAggregationInSeparateSpec From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <420320C6.8030504@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 6:14 PM, "Robert Sayre" wrote: >> leaving things as they are >> and deferring deciding how to handle aggregation would irreversibly >> enshrine HeadInEntry into the format, which all of the current >> organizational proposals are trying to replace. > > That's right. Besides, HeadInEntry is trivial to do as an extension, so > there's no reason to leave it in. +1 to HeadInEntry being removed from the 1.0 spec. e. From owner-atom-syntax@mail.imc.org Fri Feb 4 05:05:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08742 for ; Fri, 4 Feb 2005 05:05:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149wdJR082807; Fri, 4 Feb 2005 01:58:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j149wdcW082806; Fri, 4 Feb 2005 01:58:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149wc5Q082795 for ; Fri, 4 Feb 2005 01:58:38 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cx0EW-0007y7-NR for atom-syntax@imc.org; Fri, 04 Feb 2005 09:58:36 +0000 Message-ID: <4203474A.5060909@franklinmint.fm> Date: Fri, 04 Feb 2005 04:58:34 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: issue roundup Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I am getting sick of arguing with you people. :) Here is my opinion on every open issue, FWIW. I doubt any of my opinions will be controversial. You might disagree with one or two of them, but I'm guessing I predicted the WGs feelings pretty well. It's probably a waste of your time to argue about your pet Pace for another couple weeks. Listen to Paul. ------------------------------------------------------------------- HeadInEntry - Fine keep it. I think it's a stupid way to do one-item feeds, but it doesn't hurt anything, and I'm not going to explore your strange religion any more than I already have. PaceExtensionConstruct - a.k.a. don't put stuff in stupid places. The text there is close enough to give to the editors. PaceFormatSecurity - Could live with this if I had to, but mine is way better. PaceSecuritySection - Yes, let's use this one. PaceIconAndImage, PaceEnclosuresAndPix - Use @rel="icon", not a new element (we never settled any meaning for atom:link, so html convention wins). Use @rel="enclosure". Use an image element if you want sizes, otherwise use @rel="image" and 1:1. Don't limit it to atom:head, haven't you ever read a livejournal? We already have @length, please read the draft before writing a Pace. PaceMultipleImages - No. No. No. PaceLinkRelVia - people already use it, it's cool, and straightforward. Yes please. PaceCollection - overloaded term. how about "trough"? PaceMustBeWellFormed - Horrible. -1. I've explained why many times, yet people persist in applying the term "well-formed" whenever someone does something stupid with XML. PaceOrderSpecAlphabetically - Sure. PaceRemoveVersionAttr - +1, people just change formats and leave the version number "for compatibility". PaceRemoveInfoAndHost - World Record Consensus. +1. PaceTextRules - purports to tighten up rules, but uses only MAY and SHOULD. I would say "undefined" instead of MAY about xml:space. I wish we could say "clients will do this" instead of SHOULD. -0 PaceXhtmlNamespaceDiv - -0 PaceAggregationInSeparateSpec- How about PaceAggregationInSeparateWG? PaceCommentFeeds - link @rel="comments". Sure, ok. PaceFeedState, PaceNoFeedState - a good effort by mnot to set up a dichotomy and therefore appear to compromise when the less radical one is chosen. I want to reject both of them. Archiving - Atom is perfectly good for archiving blogs. Most objections venture into archiving the state of a web server. Some things you might need if you were going to do that: A way to represent negotiated resources, a way to represent source and derived resources, a way to represent resources which act on others... all the stuff you would need to serialize the state of Movable Type. I just use mysqldump. PaceAggregationDocument - Kinda scary, but also pointless. PaceFeedRecursive - Scarier, but more useful. PaceEntriesElement - Really rather useful, but the scariest of all. These are so scary, Tim called them SGML/Lisp/ArchitectureAstronautics all at once. Note to Tim: It's faster if you just say "C++". Obviously, these aren't going to happen. OK. ------------------------------------------------------------------- I think that about covers it. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 05:08:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08816 for ; Fri, 4 Feb 2005 05:08:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149xriD083288; Fri, 4 Feb 2005 01:59:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j149xrJB083287; Fri, 4 Feb 2005 01:59:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j149xpBK083268 for ; Fri, 4 Feb 2005 01:59:52 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 23:00:37 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 20:59:50 +1100 Subject: Re: New Pace: PaceAggregationInSeparateSpec From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <2bcdc7c405020323486611154a@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 4/2/05 6:48 PM, "James Snell" wrote: > I agree with this so long as there is a core mechanism that allows a > standalone entry to identify the feed to which it belongs. That > mechanism does not have to be atom:head, but it does need to be part > of the core. hmmm ... it could even be: e. From owner-atom-syntax@mail.imc.org Fri Feb 4 05:24:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09902 for ; Fri, 4 Feb 2005 05:24:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14A2fiO084283; Fri, 4 Feb 2005 02:02:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14A2ft8084282; Fri, 4 Feb 2005 02:02:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14A2eK3084228 for ; Fri, 4 Feb 2005 02:02:40 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 20661 messnum 5124198 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 4 Feb 2005 10:02:33 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 20661) with SMTP; 4 Feb 2005 10:02:33 -0000 Message-ID: <42034835.2010100@dehora.net> Date: Fri, 04 Feb 2005 10:02:29 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: Organization Use Cases References: <41FFEF0D.1090200@gmx.de> <420125F2.7080402@franklinmint.fm> <420134D3.2090400@franklinmint.fm> <265086a959e5bf339cecb7adb98a8f76@sun.com> <2bcdc7c4050203214259917c99@mail.gmail.com> In-Reply-To: <2bcdc7c4050203214259917c99@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James Snell wrote: > 6. Handle the problem in a non-core extension. I'm inclined to keep our options open on these use-cases being in or out of core. We don't have an extension mechanism yet other than atom:link[@rel]. Certainly Atom format work to date hasn't been framed as getting the evaluation of extensions right. It's might be difficult to add meaningful stuff later when there's no design for adding meaningful stuff today. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 4 05:33:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10580 for ; Fri, 4 Feb 2005 05:33:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14ANnPU091434; Fri, 4 Feb 2005 02:23:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14ANnVH091431; Fri, 4 Feb 2005 02:23:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14AMusC090722 for ; Fri, 4 Feb 2005 02:23:48 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Fri, 4 Feb 2005 23:22:21 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Fri, 04 Feb 2005 21:21:34 +1100 Subject: Re: PaceRemoveVersionAttr From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4203460F.7010901@dehora.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I just had a thought (astounding!) If we remove the version attribute and change the namespace only when there is a backwards incompatible spec revision, and assume mustIgnore for unrecognised elements from any minor version updates ... then this leaves the door open for someone to produce feeds with any ad hoc element, even elements which are not in any updated Atom specification. How would a feed validator react to something like this: ... ... ... It can't say isn't allowed in this feed, because it doesn't know if was introduced in Atom 1.1. If the validator is updated to know about Atom 1.1, the same problem exists: it doesn't know if it came from 1.2. One of the criticisms I've seen for OPML is that anyone can add any element or attribution of their own invention anywhere any time, and that this has led to xml-soup. Do we want to see the same future for Atom? e. From owner-atom-syntax@mail.imc.org Fri Feb 4 05:36:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10809 for ; Fri, 4 Feb 2005 05:36:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14ASQEb093254; Fri, 4 Feb 2005 02:28:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14ASQTn093253; Fri, 4 Feb 2005 02:28:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14ASOLX093239 for ; Fri, 4 Feb 2005 02:28:25 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so421803rne for ; Fri, 04 Feb 2005 02:28:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=PX44Yu4+MMArdGwmdtPPfLekZ4alKIJ+AfuYJSXDAfjnEGeFf00aBdlTdp8HBAduX2asled0QMUFKiVlE5UEmgPrmeacY9eu2fwb5EStklo2v5ChxRFCuvjz8P8NaAm1Y1QDX5wbHhMCtU7baDJ1aFsU8gt0IOq63YsHF5eTfvk= Received: by 10.38.71.71 with SMTP id t71mr99874rna; Fri, 04 Feb 2005 00:41:44 -0800 (PST) Received: by 10.38.72.20 with HTTP; Fri, 4 Feb 2005 00:41:44 -0800 (PST) Message-ID: <2bcdc7c405020400413a09f25f@mail.gmail.com> Date: Fri, 4 Feb 2005 00:41:44 -0800 From: James Snell Reply-To: James Snell To: Henry Story Subject: Re: New Pace: PaceAggregationInSeparateSpec Cc: Robert Sayre , Antone Roundy , atom-syntax@imc.org In-Reply-To: <3fa72be3956ca366d82c0a15ea02d698@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> <2bcdc7c405020323486611154a@mail.gmail.com> <42032980.7040400@franklinmint.fm> <2bcdc7c405020400052badd70e@mail.gmail.com> <3fa72be3956ca366d82c0a15ea02d698@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > I have heard interesting arguments "It's all about the Entries, stupid!" > that made the opposite assessment: namely that the entries are what is > important, and that what feed an Entry is part of, is a accident of > life. > > The idea there is that Entries are the stand alone entities. They can > be made to be part of any feed whatsoever. A feed in this > conceptualization, > is a little like a search engine result listing where the pages they > refer > to are like entries (notice that search engine results pages are just a > type of web page too). Which feed your entry appears in will depend very > much on the type of query the user of the search engine made. > OK, I can buy that, as long as that is indeed how things are supposed to be defined. Note, however, that the Atom syntax spec focuses on feeds as resources and that entries just happen to be contained in feeds. e.g. from Section 1: "Atom is an XML-based document format which describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata." If the assertion that the entries are the standalone entities is correct, then the text in the spec needs to be changed to reflect that assertion. Granting the assumption that the entries are the standalone entities and feeds are merely just a convenient container for entries, the identification of containing parent-feed becomes less important. The need to identify where the entity came from, however, obviously still remains.. although not necessarily as a core requirement. Back to the original point about HeadInEntry: HeadInEntry is not required to achieve the origin/container identification, regardless of whether or not origin/container identification should be part of the core. If there are no other reasons why HeadInEntry should remain in the core, then by all means, rip that sucker out of there. PaceAggregationInSeparateSpec by no means locks it in place. > Of course if an entry has a tag such as "origin" (which used to be on > the > table) then the entry it points to would be part of the metadata of the > entry and so be a legitimate way of creating special selection of > entries. > > > Henry Story > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 08:07:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23511 for ; Fri, 4 Feb 2005 08:07:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14AcDiF097483; Fri, 4 Feb 2005 02:38:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14AcD1p097482; Fri, 4 Feb 2005 02:38:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14AcDoN097471 for ; Fri, 4 Feb 2005 02:38:13 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.103]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cx0S9-00087C-PC; Fri, 04 Feb 2005 10:12:41 +0000 Message-ID: <42034A96.5040400@franklinmint.fm> Date: Fri, 04 Feb 2005 05:12:38 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: Don't mess with HeadInEntry! References: <200502040829.CNH96776@ms8.netsolmail.com> In-Reply-To: <200502040829.CNH96776@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Robert Sayre wrote: > >>HeadInEntry is trivial to do as an extension, so there's no >>reason to leave it in. > > There are a number of excellent reasons to leave it in! I totally disagree! But you can keep it! (see other mail :) > 1. Just about the only functional "advantage" that Atom has over RSS > is that HeadInEntry provides core support for aggregated feeds. If you're > unwilling to innovate in even this one tiny spot, why the heck bother with > this effort at all? Perhaps we should all join Dare over in RSS-land... With > Microsoft being so anti-Atom, we need *some* argument for expending the > effort and political capital needed to support this format! We'll do a SOAP protocol and they can call it "Atom Indigo". Don't you think that sounds approproately cool but also banal? Besides, if you move to RSS-land, Dare will have to move somewhere else (XAML-land?) and call people morons from there. > We decided to support HeadInEntry. It doesn't make sense to back off > now. Deferring HeadInEntry to a non-core extension essentially kills it and > ensures that Atom use will provide virtually no advantage to anyone who is > building aggregated feeds. Oh, that's not true. No one will call you names when you build extensions, and there will always be titles, ids, and dates--like other formats that work. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 08:35:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25851 for ; Fri, 4 Feb 2005 08:35:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14DOtGF050056; Fri, 4 Feb 2005 05:24:55 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14DOsv6050052; Fri, 4 Feb 2005 05:24:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14DOqII050028 for ; Fri, 4 Feb 2005 05:24:52 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j14CmeCh015429; Fri, 4 Feb 2005 07:48:40 -0500 (EST) Message-ID: <42036F2A.1010504@intertwingly.net> Date: Fri, 04 Feb 2005 07:48:42 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Atom Syntax Subject: Re: PaceProfile - new References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > I tried to post this to the Wiki, but it said I wasn't allowed to. Hmm. I have a spam throttle that limits the number of unique pages a person who is not logged in can edit per hour. I'll send you login info. - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Feb 4 08:52:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27237 for ; Fri, 4 Feb 2005 08:52:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14DeBN6055915; Fri, 4 Feb 2005 05:40:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14DeBGM055914; Fri, 4 Feb 2005 05:40:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtai19.cox.net (fed1rmmtai19.cox.net [68.230.241.40]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14De9Gt055832 for ; Fri, 4 Feb 2005 05:40:10 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao01.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050204084505.LLWX13222.fed1rmmtao01.cox.net@[192.168.0.100]>; Fri, 4 Feb 2005 03:45:05 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2fb7279fb4ac8fd7d64392ad800ae5a7@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: On organization and abstraction Date: Fri, 4 Feb 2005 00:45:06 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 3, 2005, at 6:37 PM, Tim Bray wrote: > > On reflection, I am growing very negative on almost all of the > "Organization" Paces, including FeedRecursive, PaceEntriesElement, > PaceCollection. Here's why: they represent to increase the level of > abstraction in Atom, and in my experience, when the goal is > interoperability across the network, abstraction hurts. Hmm, I am either suffering from a bad case of ennui at the moment or I have just completely lost track of why atom needs a syndication format in the first place, or perhaps both. I think your summary reflects the email discussion, not the content of those paces. > I would like it if the markup found in Atom documents was as close > as possible to a typical human mental model. ... of what? Personally, I think that is the main problem with all of the syndication formats -- they reify an interaction model rather than a data model. > The word "feed" has entered the vocabulary, even the non-geek > vocabulary, and the notion that there are "things" (entries, stories, > items, whatever) in "feeds" likewise. Any attempt to abstract away > and generalize along the lines of "well, a feed is really an entry" or > "well, an entry is really a feed" or "really, they're all just web > resources and collections" is dangerously close to verging on > Architecture Astronautics. Entry is a data model that easily fits the XML format, assuming we ignore (for the moment) that entries and entry summaries are actually quite different. It would be nice if atom would define a distinct data model for entry first, before it got tied up in the details of how feeds are supposed to work. Feed is an interaction model. It has more to do with the pipe in pipe-and-filter and the slash in client/server than the actual data passed in syndication. It carries a lot of semantic baggage, which is fine when that is the baggage you want to define. Other than that, it is just data, and all data looks like an entry because (so far) entry is completely undefined. The purpose of PaceFeedRecursive is to simplify the feed data format by specifying a particular method of answering the data relationship question via XML containment. With all due respect, that is far more concrete a solution than what is currently in the draft, much easier to specify, and easily implemented by existing XML tools without the need for (or conflict with) RDF/XML. My interest is in simplification, not abstraction. For example, the draft wastes a lot of text talking in the abstract about various constructs rather than simply defining one element for each of those constructs. Likewise, it talks about documents in a very abstract way, whereas it really should define entry first (and completely) before even talking about feed documents. It defines an element, atom:head, that serves no useful purpose whatsoever (XML is ordered and there is nothing preventing the syndication format from requiring that entries be provided last) while at the same time making a mess out of atom extensibility. Having said all that, I have no objection to withdrawing PaceFeedRecursive and replacing it with a PaceHeadless that simply removes atom:head. My interest in atom is almost all on the back-end (content management) and that is the one piece that dirties a clean implementation via Jackrabbit (or any CMS based on JSR 170). I think one reason that Robert has been exploring various alternatives is because atom is not clear on what an entry should be, which is a separate issue that has very little to do with the organization paces, and yet that is the one capability that distinguishes atom from the other syndication formats. OTOH, if people really want just a syndication format containing typical blog entries, then I strongly recommend just using the proposed RSS 1.1 and move on to greener pastures. Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-atom-syntax@mail.imc.org Fri Feb 4 10:15:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04948 for ; Fri, 4 Feb 2005 10:15:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14F16g1064782; Fri, 4 Feb 2005 07:01:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14F16lH064781; Fri, 4 Feb 2005 07:01:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14F0q4U064721 for ; Fri, 4 Feb 2005 07:00:59 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [192.168.1.101] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j14F0Mkc011994; Fri, 4 Feb 2005 10:00:23 -0500 (EST) Message-ID: <42038E08.2040206@intertwingly.net> Date: Fri, 04 Feb 2005 10:00:24 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceRemoveVersionAttr References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > > I just had a thought (astounding!) > > If we remove the version attribute and change the namespace only when there > is a backwards incompatible spec revision, and assume mustIgnore for > unrecognised elements from any minor version updates ... then this leaves > the door open for someone to produce feeds with any ad hoc element, even > elements which are not in any updated Atom specification. > > How would a feed validator react to something like this: > > > ... > > ... > ... > > > > It can't say isn't allowed in this feed, because it doesn't know if > was introduced in Atom 1.1. If the validator is updated to know about > Atom 1.1, the same problem exists: it doesn't know if it came from 1.2. > > One of the criticisms I've seen for OPML is that anyone can add any element > or attribution of their own invention anywhere any time, and that this has > led to xml-soup. > > Do we want to see the same future for Atom? Whether the feedvalidator flags such an element or not, the spec declares (or will declare once the spec is updated to reflect the last round from the workgroup) such elements as invalid. Furthermore, having things like the feedvalidator flag unknown elements in the Atom namespace as invalid is exactly what makes it safe for future authors or revisions of the Atom specification to add new elements in the Atom namespace without fear of conflicting with existing feeds. What this does mean is that the feedvalidator either needs to be updated when new versions of Atom come out, or become increasingly irrelevant and obsolete as new validators assume this role (possibly something as simple as a RelaxNG schema). - Sam Ruby From owner-atom-syntax@mail.imc.org Fri Feb 4 10:35:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07391 for ; Fri, 4 Feb 2005 10:35:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FGAjB065726; Fri, 4 Feb 2005 07:16:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14FGAdl065725; Fri, 4 Feb 2005 07:16:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao08.cox.net (fed1rmmtao08.cox.net [68.230.241.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FGALe065717 for ; Fri, 4 Feb 2005 07:16:10 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050204151605.OOPQ7567.fed1rmmtao08.cox.net@[192.168.0.100]> for ; Fri, 4 Feb 2005 10:16:05 -0500 Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: "Roy T. Fielding" Subject: PaceHeadless Date: Fri, 4 Feb 2005 07:16:04 -0800 X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mostly for the sake of completeness... http://www.intertwingly.net/wiki/pie/PaceHeadless which takes the recursion out of PaceFeedRecursive, though I still prefer that one because it doesn't lose hierarchy. PaceHeadless also adds an atom:feeder child element of atom:entry, so that the functionality of PaceHeadInEntry is preserved. Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-atom-syntax@mail.imc.org Fri Feb 4 10:52:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08751 for ; Fri, 4 Feb 2005 10:52:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FfdE6067396; Fri, 4 Feb 2005 07:41:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14FfdEV067395; Fri, 4 Feb 2005 07:41:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FfcAx067387 for ; Fri, 4 Feb 2005 07:41:39 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4067751A34; Fri, 4 Feb 2005 10:41:38 -0500 (EST) In-Reply-To: <4203460F.7010901@dehora.net> References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceProfile - new Date: Fri, 4 Feb 2005 07:41:33 -0800 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j14FfdAx067390 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill, I'm sorry, I don't think I get what you're saying; the words all make sense, but I don't know how you got here. Atom currently constrains feed data (e.g., you MUST have a title, there MUST only be one) based on the most common use case; bloggling/news syndication. How does this move towards "agents enforcing policy on one another?" If anything, the Pace makes it *less* likely that publishers will make assumptions about how data will be processed downstream; as Atom is currently specified, there are lots of such assumptions built in. The Pace doesn't place any requirements on Atom Processors WRT @profile; it's just an advisory flag that tells it what kinds of metadata it can count on appearing in the feed. On Feb 4, 2005, at 1:53 AM, Bill de hÓra wrote: > One concern I have is that I don't want to see feed data constrained > according to usecases (ie system monitoring); that makes the data less > useful and goes down the route of publishers telling clients how to > write their applications or making assumptions on how data will be > processed downstream. While I believe that claiming Atom is a > container for metadata is good, I doubt that profiling represents a > more flexible approach - it moves us away from agents coordinating > together to agents enforcing policy on one another via a profiling > mechanism. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 11:01:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09846 for ; Fri, 4 Feb 2005 11:01:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FqUg4069860; Fri, 4 Feb 2005 07:52:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14FqTY4069859; Fri, 4 Feb 2005 07:52:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FqSaS069782 for ; Fri, 4 Feb 2005 07:52:29 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050204155221015009ffhre>; Fri, 4 Feb 2005 15:52:21 +0000 Date: Fri, 4 Feb 2005 08:52:19 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceAggregationDocument2 posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceAggregationDocument2 Simplified version of PaceAggregationDocument: adds an document element without attempting to redefine all Atom elements as either metadata or containers in order to make the impact on the current specification easier to gauge. From owner-atom-syntax@mail.imc.org Fri Feb 4 11:09:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10287 for ; Fri, 4 Feb 2005 11:09:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FxldW071339; Fri, 4 Feb 2005 07:59:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Fxlaa071338; Fri, 4 Feb 2005 07:59:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14FxkIA071330 for ; Fri, 4 Feb 2005 07:59:47 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020415594101300kbmnge>; Fri, 4 Feb 2005 15:59:41 +0000 Date: Fri, 4 Feb 2005 08:59:36 -0700 Subject: Re: Don't mess with HeadInEntry! Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200502040829.CNH96776@ms8.netsolmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 01:29 AM, Bob Wyman wrote: > 4. We've been talking about HeadInEntry ever since I proposed it > back in June at the Atom Community meeting. On numerous occasions, the > group > as a whole has rejected the various "feed of feed" proposals as overly > complex and unnecessary. It is a bit bizarre to see all this being > rehashed > in a rush as we drive towards a Last Call. It seems to me that the main reason for the objections to "feed of feeds" was that it seemed to open the way to unlimited recursion. I too am a little surprised to see proposals for recursive feeds of feeds--that's what sparked the idea of the Aggregation Document you've taken such a disliking to. > 6. All of the alternatives that have been proposed require drastic > and unlikely modifications to the design and architecture of readers. > (i.e. > stuff like adding an aggregation document!!) Such proposals are not > viable > alternatives no matter how sweet one might find their abstractions... I suspect that the large volume of proposed text that PaceAggregationDocument lifted from PaceFeedRecursive made it look a lot more drastic than it really is. In both of those proposals, the proposed text was largely identical to what's in the current draft--it's just been moved around and one or two little changes made. However, there is a point to the argument that we should minimize how much mucking around with do with things right now, so I've posted PaceAggregationDocument2, which only proposes the changes necessary to create an Aggregation Document. As for HeadInEntry, the best argument I see for it if we adopt a containment-based aggregation mechanism is that Entry Documents may need to be able to refer to their feeds for context. I can think of three ways to handle that: 1) A link to their feed 2) Use a one-entry Feed Document instead of an Entry Document 3) Allow HeadInEntry in Entry Documents only From owner-atom-syntax@mail.imc.org Fri Feb 4 11:23:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11668 for ; Fri, 4 Feb 2005 11:23:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14G2mLN071712; Fri, 4 Feb 2005 08:02:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14G2m7H071711; Fri, 4 Feb 2005 08:02:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14G2lV4071705 for ; Fri, 4 Feb 2005 08:02:47 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14G2kdt008116 for ; Fri, 4 Feb 2005 09:02:47 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBE003019TSNW@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 04 Feb 2005 11:02:49 -0500 (EST) Received: from localhost (vpn-129-150-33-242.Central.Sun.COM [129.150.33.242]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBE00MYH9WK40@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:02:49 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cx5uW-0001bu-R0 for atom-syntax@imc.org; Fri, 04 Feb 2005 11:02:20 -0500 X-URL: http://nwalsh.com/ Date: Fri, 04 Feb 2005 11:02:17 -0500 From: Norman Walsh Subject: Re: PaceRemoveInfoAndHost In-reply-to: <0d10ceea13dc576ea28878e66290c69f@mnot.net> To: Atom Syntax Message-id: <871xbwqpo6.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <42011C03.5070309@franklinmint.fm> <0d10ceea13dc576ea28878e66290c69f@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Mark Nottingham was heard to say: | +1 | | Welcome to the club :) +1. I'll join. :-) Be seeing you, norm =2D-=20 Norman Walsh | A man may by custom fortify himself http://nwalsh.com/ | against pain, shame, and suchlike | accidents; but as to death, we can | experience it but once, and are all | apprentices when we come to it.-- | Montaigne --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA5yJOyltUcwYWjsRAs6nAJ43L/hhzG5PkksOv22hEbF0n2zG9wCfe/d1 gsbknl4h8+CtPU17NchUvEg= =fbXq -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Feb 4 11:47:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13522 for ; Fri, 4 Feb 2005 11:47:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GMife073047; Fri, 4 Feb 2005 08:22:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14GMih0073046; Fri, 4 Feb 2005 08:22:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail00.svc.cra.dublin.eircom.net (mail00.svc.cra.dublin.eircom.net [159.134.118.16]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14GMXmP072988 for ; Fri, 4 Feb 2005 08:22:43 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 9806 messnum 4161342 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 4 Feb 2005 16:15:43 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail00.svc.cra.dublin.eircom.net (qp 9806) with SMTP; 4 Feb 2005 16:15:43 -0000 Message-ID: <42039FAB.3080603@dehora.net> Date: Fri, 04 Feb 2005 16:15:39 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceProfile - new References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > Bill, > > I'm sorry, I don't think I get what you're saying; the words all make > sense, but I don't know how you got here. > > [../] > The Pace doesn't place any requirements on Atom Processors WRT @profile; > it's just an advisory flag that tells it what kinds of metadata it can > count on appearing in the feed. Ok, I'll calm down and try again. If the advisory @profile scopes at the level of the feed, I think that's too broad a scope. It needs to scope at the level of the entry, or it's liable to becomes meaningless when entries are mixed and matched. I can barely figure out how to class individual entries, never mind entire feeds. Maybe there's a use case I'm not getting. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 4 11:49:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13669 for ; Fri, 4 Feb 2005 11:49:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GSHOr073363; Fri, 4 Feb 2005 08:28:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14GS35Z073348; Fri, 4 Feb 2005 08:28:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GQwKP073242 for ; Fri, 4 Feb 2005 08:27:53 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020416160901100ci3sve>; Fri, 4 Feb 2005 16:16:09 +0000 Date: Fri, 4 Feb 2005 09:16:08 -0700 Subject: Re: PaceIconAndImage Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <13E78FF8-76C8-11D9-976E-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote: > Also, why limit this to feed/head, and not entry? If we ARE going to limit images to feeds, then please, let's change the name to "logo". If it were "logo", I'd agree it doesn't belong in entry. From owner-atom-syntax@mail.imc.org Fri Feb 4 11:58:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14342 for ; Fri, 4 Feb 2005 11:58:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Gd9W6074067; Fri, 4 Feb 2005 08:39:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Gd7JJ074063; Fri, 4 Feb 2005 08:39:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GcRXK073957 for ; Fri, 4 Feb 2005 08:39:05 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cx6SG-0004be-Ts; Fri, 04 Feb 2005 16:37:13 +0000 Message-ID: <4203A4B7.6090109@franklinmint.fm> Date: Fri, 04 Feb 2005 11:37:11 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> In-Reply-To: <87hdkspad2.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > The 05 draft of the Atom format says: > > I know we're writing an IETF document, but I think there's going to be > a lot of off-the-shelf XML software that understands xsd:dateTimes and > I think it would be a lot better if we defined Date Constructs in > terms of W3C XML Schema Part 2 than RFC 3339. > > I propose that we change the spec to do so. > I agree. I was just writing a protocol implementation in Ruby On Rails (CRUDs very fast, btw). When I got to the part on date formats, I used xsd:dateTime code that was already done, figuring that's what everyone else will do. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 12:07:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14981 for ; Fri, 4 Feb 2005 12:07:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GtYrw075826; Fri, 4 Feb 2005 08:55:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14GtY0j075825; Fri, 4 Feb 2005 08:55:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14GtXpo075801 for ; Fri, 4 Feb 2005 08:55:33 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 16:55:18 -0000 Received: from p50825F09.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.95.9) by mail.gmx.net (mp014) with SMTP; 04 Feb 2005 17:55:18 +0100 X-Authenticated: #1915285 Message-ID: <4203A8F0.8020202@gmx.de> Date: Fri, 04 Feb 2005 17:55:12 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Norman Walsh , Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4203A4B7.6090109@franklinmint.fm> In-Reply-To: <4203A4B7.6090109@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Norman Walsh wrote: > >> The 05 draft of the Atom format says: >> >> I know we're writing an IETF document, but I think there's going to be >> a lot of off-the-shelf XML software that understands xsd:dateTimes and >> I think it would be a lot better if we defined Date Constructs in >> terms of W3C XML Schema Part 2 than RFC 3339. >> >> I propose that we change the spec to do so. >> > > I agree. I was just writing a protocol implementation in Ruby On Rails > (CRUDs very fast, btw). When I got to the part on date formats, I used > xsd:dateTime code that was already done, figuring that's what everyone > else will do. But in that case, we'll need to profile xsd:dateTime. For instance, that one allows timestamps without timezone (with a distinct meaning!). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 12:25:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16612 for ; Fri, 4 Feb 2005 12:25:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HAhYg077084; Fri, 4 Feb 2005 09:10:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HAhrc077083; Fri, 4 Feb 2005 09:10:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HAcT5077061 for ; Fri, 4 Feb 2005 09:10:39 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cx6yS-0004z9-AC; Fri, 04 Feb 2005 17:10:28 +0000 Message-ID: <4203AC82.1000308@franklinmint.fm> Date: Fri, 04 Feb 2005 12:10:26 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Roy T. Fielding" CC: Tim Bray , Atom Syntax Subject: Re: On organization and abstraction References: <2fb7279fb4ac8fd7d64392ad800ae5a7@gbiv.com> In-Reply-To: <2fb7279fb4ac8fd7d64392ad800ae5a7@gbiv.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > > Entry is a data model that easily fits the XML format, assuming > we ignore (for the moment) that entries and entry summaries are > actually quite different. It would be nice if atom would define > a distinct data model for entry first, before it got tied up in > the details of how feeds are supposed to work. > Agree. *looks for the well-formed log entry. > > The purpose of PaceFeedRecursive is to simplify the feed data > format by specifying a particular method of answering the data > relationship question via XML containment. Now that you've written PaceRemoveHeadElement (Note to Bob: it still does what you want), I think that is what will probably happen. Secondly, it would be easy to turn it into PaceFeedRecursive at some point in the future. > > My interest is in simplification, not abstraction. For example, > the draft wastes a lot of text talking in the abstract about > various constructs rather than simply defining one element for > each of those constructs. Person, Date, and Text constructs all save space because they avoid repetitive requirements, and they match up nicely with the Relax NG. I'm pretty sure the group has agreed to drop Service constructs, and mnot has already moved atom:id into an element definition for -06. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 12:29:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17360 for ; Fri, 4 Feb 2005 12:29:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HNPQk078218; Fri, 4 Feb 2005 09:23:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HNPuR078217; Fri, 4 Feb 2005 09:23:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HNOnS078210 for ; Fri, 4 Feb 2005 09:23:24 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j14HNMiI029383 for ; Fri, 4 Feb 2005 09:23:22 -0800 (PST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBE00501DFBXV@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 04 Feb 2005 12:23:21 -0500 (EST) Received: from localhost (vpn-129-150-33-242.Central.Sun.COM [129.150.33.242]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBE00M54DMV40@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 04 Feb 2005 12:23:21 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cx7Aa-0002Tk-Ha for atom-syntax@imc.org; Fri, 04 Feb 2005 12:23:00 -0500 X-URL: http://nwalsh.com/ Date: Fri, 04 Feb 2005 12:22:55 -0500 From: Norman Walsh Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: <4203A8F0.8020202@gmx.de> To: Atom Syntax Message-id: <87r7jwme8g.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <87hdkspad2.fsf@nwalsh.com> <4203A4B7.6090109@franklinmint.fm> <4203A8F0.8020202@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Julian Reschke was heard to say: | Robert Sayre wrote: [...] |> I agree. I was just writing a protocol implementation in Ruby On |> Rails (CRUDs very fast, btw). When I got to the part on date |> formats, I used xsd:dateTime code that was already done, figuring |> that's what everyone else will do. | | But in that case, we'll need to profile xsd:dateTime. For instance, | that one allows timestamps without timezone (with a distinct meaning!). Or not. I propose that we say that Date Constructs MUST be valid xsd:dateTime values and SHOULD include an explicit time zone. Heck, I could even live with SHOULD be in UTC. If pressed, I could live with MUST be in UTC. But the evidence suggests that software is, in practice, going to use libraries that recognize and process xsd:dateTime values, so defining it in some other way is just going to lead to deviation from the spec. Be seeing you, norm =2D-=20 Norman Walsh | He that shuns trifles must shun the http://nwalsh.com/ | world.--George Chapman --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA69vOyltUcwYWjsRAiOXAJwLV0iX8skSxYqITcWKW4IfM7yhVgCghw+L 7QUk2JIIqrG8d7dSOiaF15k= =M1cv -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Feb 4 12:30:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17439 for ; Fri, 4 Feb 2005 12:30:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HM5Ul078062; Fri, 4 Feb 2005 09:22:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HM5WC078061; Fri, 4 Feb 2005 09:22:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14HM4Uk078031 for ; Fri, 4 Feb 2005 09:22:04 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 17:21:49 -0000 Received: from p50825F09.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.95.9) by mail.gmx.net (mp010) with SMTP; 04 Feb 2005 18:21:49 +0100 X-Authenticated: #1915285 Message-ID: <4203AF2C.2090304@gmx.de> Date: Fri, 04 Feb 2005 18:21:48 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> In-Reply-To: <87hdkspad2.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > The 05 draft of the Atom format says: > > 3.3 Date Constructs > > A Date construct is an element whose content MUST conform to the > date-time BNF rule in [RFC3339]. > > I'm actually using xsd:dateTime in the RELAX NG grammar and I went off > to look at RFC 3339 thinking I might write a regex to do that instead, > since that's what the spec says. Then I got to wondering just how similar > the two definitions actually are. In some private correspondence, Paul > Byron made the following observations: > > 1. RFC 3339 allows lower- and upper-case 'T' and 'Z', while > xsd:dateTime requires upper-case only. There is a note in sect 5.6 > of RFC 3339 which says: > > This date/time format may be used in some environments or > contexts that distinguish between the upper- and lower-case > letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use > this format in such environments MAY further limit the date/time > syntax so that the letters 'T' and 'Z' used in the date/time > syntax must always be upper case. Applications that generate > this format SHOULD use upper case letters. I don't see this as a problem. We can either allow both (default), or explicitly restrict it. > 2. RFC 3339 allows the replacement of the 'T' with a space which > xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC > 3339 isn't actually a "profile of ISO 8601" as it claims]. As far as I can tell, ISO 8601 allows this. > 3. RFC 3339 does not allow the hour 24 but xsd:dateTime does (in > xsd:dateTime [as in ISO 8601] 00 & 24 both represent midnight, but > 24 means the end of one day while 00 means the start of the next) That looks like a useful restriction to me... > 4. RFC 3339 gives a different semantic to a timezone offset of -00:00 from > +00:00 and Z which xsd:dateTime (and to the best of my knowledge > ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads: > > If the time in UTC is known, but the offset to local time is > unknown, this can be represented with an offset of "-00:00". This > differs semantically from an offset of "Z" or "+00:00", which > imply that UTC is the preferred reference point for the specified > time. RFC2822 [IMAIL-UPDATE] describes a similar convention for > email. I'm not sure how this is relevant. All three representations (Z, +00:00, -00:00) refer to the same instant in time. > He goes on to suggest that there may be other differences, but these > are the ones he noticed. That's enough for me: they are different. > > I know we're writing an IETF document, but I think there's going to be > a lot of off-the-shelf XML software that understands xsd:dateTimes and > I think it would be a lot better if we defined Date Constructs in > terms of W3C XML Schema Part 2 than RFC 3339. > > I propose that we change the spec to do so. So what do you do with something like 2005-02-04T17:20:00 ? -> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we may have to profile one of them. In which case I'd prefer to stick with RFC3339. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 12:37:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13521 for ; Fri, 4 Feb 2005 11:47:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GM6sF072952; Fri, 4 Feb 2005 08:22:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14GM1Tb072917; Fri, 4 Feb 2005 08:22:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com ([192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14GLEFI072649 for ; Fri, 4 Feb 2005 08:21:51 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14GItet020738 for ; Fri, 4 Feb 2005 09:18:59 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBE00901AMYCD@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 04 Feb 2005 11:19:01 -0500 (EST) Received: from localhost (vpn-129-150-33-242.Central.Sun.COM [129.150.33.242]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBE00M1NANC40@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:19:01 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cx69z-0001na-U2 for atom-syntax@imc.org; Fri, 04 Feb 2005 11:18:19 -0500 X-URL: http://nwalsh.com/ Date: Fri, 04 Feb 2005 11:18:17 -0500 From: Norman Walsh Subject: xsd:dateTime vs. RFC 3339 To: Atom Syntax Message-id: <87hdkspad2.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable The 05 draft of the Atom format says: 3.3 Date Constructs A Date construct is an element whose content MUST conform to the date-time BNF rule in [RFC3339]. I'm actually using xsd:dateTime in the RELAX NG grammar and I went off to look at RFC 3339 thinking I might write a regex to do that instead, since that's what the spec says. Then I got to wondering just how similar the two definitions actually are. In some private correspondence, Paul Byron made the following observations: 1. RFC 3339 allows lower- and upper-case 'T' and 'Z', while xsd:dateTime requires upper-case only. There is a note in sect 5.6 of RFC 3339 which says: This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters. 2. RFC 3339 allows the replacement of the 'T' with a space which xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC 3339 isn't actually a "profile of ISO 8601" as it claims]. 3. RFC 3339 does not allow the hour 24 but xsd:dateTime does (in xsd:dateTime [as in ISO 8601] 00 & 24 both represent midnight, but 24 means the end of one day while 00 means the start of the next) 4. RFC 3339 gives a different semantic to a timezone offset of -00:00 from +00:00 and Z which xsd:dateTime (and to the best of my knowledge ISO 8601) doesn't. Sect 4.3 of RFC 3339 reads: If the time in UTC is known, but the offset to local time is unknown, this can be represented with an offset of "-00:00". This differs semantically from an offset of "Z" or "+00:00", which imply that UTC is the preferred reference point for the specified time. RFC2822 [IMAIL-UPDATE] describes a similar convention for email. He goes on to suggest that there may be other differences, but these are the ones he noticed. That's enough for me: they are different. I know we're writing an IETF document, but I think there's going to be a lot of off-the-shelf XML software that understands xsd:dateTimes and I think it would be a lot better if we defined Date Constructs in terms of W3C XML Schema Part 2 than RFC 3339. I propose that we change the spec to do so. Be seeing you, norm =2D-=20 Norman Walsh | It is important what a man still plans http://nwalsh.com/ | at the end. It shows the measure of | injustice in his death.--Elias Canetti --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA6BJOyltUcwYWjsRAtISAJ470xJGH+I7SZCUlIyKjP20OyEzQwCdFokZ qiPUd6mxV9oQDQqfSg5h7eE= =v1SQ -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Feb 4 12:38:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18131 for ; Fri, 4 Feb 2005 12:38:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HUIqV078810; Fri, 4 Feb 2005 09:30:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HUIRZ078809; Fri, 4 Feb 2005 09:30:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HUHA3078799 for ; Fri, 4 Feb 2005 09:30:17 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14HUEdt017261 for ; Fri, 4 Feb 2005 10:30:15 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBE00801DTMRV@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 04 Feb 2005 12:30:14 -0500 (EST) Received: from localhost (vpn-129-150-33-242.Central.Sun.COM [129.150.33.242]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBE00MIODXU40@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 04 Feb 2005 12:30:14 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cx7H6-0002Xr-KW for atom-syntax@imc.org; Fri, 04 Feb 2005 12:29:44 -0500 X-URL: http://nwalsh.com/ Date: Fri, 04 Feb 2005 12:29:44 -0500 From: Norman Walsh Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: <4203AF2C.2090304@gmx.de> To: Atom Syntax Message-id: <87is58mdx3.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <87hdkspad2.fsf@nwalsh.com> <4203AF2C.2090304@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Julian Reschke was heard to say: [...] | So what do you do with something like | | 2005-02-04T17:20:00 Dunno. | -> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we | may have to profile one of them. In which case I'd prefer to stick | with RFC3339. *shrug* I've said why I think xsd:dateTime is a better choice, but you're right, we just have to pick one. Be seeing you, norm =2D-=20 Norman Walsh | A new scientific truth does not triumph http://nwalsh.com/ | by convincing its opponents and making | them see the light, but rather because | its opponents eventually die, and a new | generation grows up that is familiar | with it (Planck 1949) --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA7EIOyltUcwYWjsRAqC4AKCYtXO3JbnmKNdF96wjObTqMpdocgCfSqCZ RH/MPoSuVCyleP5khzfq278= =3neR -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Feb 4 12:40:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18293 for ; Fri, 4 Feb 2005 12:40:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HYxB7079211; Fri, 4 Feb 2005 09:34:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HYxF1079210; Fri, 4 Feb 2005 09:34:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HYmew079195; Fri, 4 Feb 2005 09:34:49 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <7067bc6089d1d61057a280f26d2334ee@mnot.net> References: <55BAAD02B0A01C5ACF58A4B0@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <7067bc6089d1d61057a280f26d2334ee@mnot.net> Date: Fri, 4 Feb 2005 09:34:47 -0800 To: Mark Nottingham , Tim Bray From: Paul Hoffman Subject: Re: Call for final Paces for consideration: deadline imminent Cc: Atom WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:55 PM -0800 2/3/05, Mark Nottingham wrote: >Walter brings up an important point; has, or when will, the drafts >be compared to the requirements in the charter? I have compared the format draft to the charter and it meets the requirements, at least in my eyes (which are the eyes of a protocol weenie but not a developer). In specific, "a complete archive of all entries in a feed" is well taken care of by our current format; it's just not explicitly called "an archive". The fact that our IDs are unique over all time means an archive of all entries that were ever in the main feed is just a bigger feed; that will work exactly as an archive with no ambiguity of elements. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Feb 4 12:41:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18343 for ; Fri, 4 Feb 2005 12:41:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HWv5U079072; Fri, 4 Feb 2005 09:32:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HWvfg079071; Fri, 4 Feb 2005 09:32:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HWueT079059 for ; Fri, 4 Feb 2005 09:32:56 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <2bcdc7c405020323486611154a@mail.gmail.com> References: <9275F693-7677-11D9-8EFA-003065EA6144@geckotribe.com> <420320C6.8030504@franklinmint.fm> <2bcdc7c405020323486611154a@mail.gmail.com> Date: Fri, 4 Feb 2005 09:32:52 -0800 To: Atom WG From: Paul Hoffman Subject: Re: New Pace: PaceAggregationInSeparateSpec Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:48 PM -0800 2/3/05, James Snell wrote: >I agree with this so long as there is a core mechanism that allows a >standalone entry to identify the feed to which it belongs. That >mechanism does not have to be atom:head, but it does need to be part >of the core. What if an entry is part of many feeds? What if someone takes an entry and puts it into a new feed? It seems like the WG has coalesced on the idea that entries can stand alone, and can also be combined into one or (many) more feeds. Any pointer from an entry to a feed would be almost instantly out-of-date, wouldn't it? The outward pointer or pointer mechanism doesn't feel like part of the core of describing entries and how to create a feed of entries. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Feb 4 12:47:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18752 for ; Fri, 4 Feb 2005 12:47:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Haon2079372; Fri, 4 Feb 2005 09:36:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Haooc079371; Fri, 4 Feb 2005 09:36:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14HanKt079364 for ; Fri, 4 Feb 2005 09:36:49 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 17:36:43 -0000 Received: from p50825F09.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.95.9) by mail.gmx.net (mp013) with SMTP; 04 Feb 2005 18:36:43 +0100 X-Authenticated: #1915285 Message-ID: <4203B2A9.8050601@gmx.de> Date: Fri, 04 Feb 2005 18:36:41 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Norman Walsh , Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4203AF2C.2090304@gmx.de> In-Reply-To: <4203AF2C.2090304@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > ... >> 2. RFC 3339 allows the replacement of the 'T' with a space which >> xsd:dateTime does not. [Note: ISO 8601 doesn't either, hence RFC >> 3339 isn't actually a "profile of ISO 8601" as it claims]. > > > As far as I can tell, ISO 8601 allows this. And anyway, what RFC3339 says is: " date-time = full-date "T" full-time NOTE: Per [ABNF] and ISO8601, the "T" and "Z" characters in this syntax may alternatively be lower case "t" or "z" respectively. This date/time format may be used in some environments or contexts that distinguish between the upper- and lower-case letters 'A'-'Z' and 'a'-'z' (e.g. XML). Specifications that use this format in such environments MAY further limit the date/time syntax so that the letters 'T' and 'Z' used in the date/time syntax must always be upper case. Applications that generate this format SHOULD use upper case letters. NOTE: ISO 8601 defines date and time separated by "T". Applications using this syntax may choose, for the sake of readability, to specify a full-date and full-time separated by (say) a space character." So as long as we normatively refer to the "date-time" production, only "T" is allowed. In general, I find RFC3339 a lot easier to read than xsd:dateTime, and for the date representations we actually want to support, they define the same meaning. Thus -1 on changing it, and +1 on possibly profiling it further. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 12:48:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18820 for ; Fri, 4 Feb 2005 12:48:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HdYWD079559; Fri, 4 Feb 2005 09:39:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HdYox079558; Fri, 4 Feb 2005 09:39:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HdXli079546 for ; Fri, 4 Feb 2005 09:39:33 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 89B0D160; Fri, 4 Feb 2005 09:39:26 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j14HdBLf017128; Fri, 4 Feb 2005 09:39:17 -0800 (PST) Date: Fri, 04 Feb 2005 09:39:13 -0800 From: Walter Underwood To: Norman Walsh , Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 Message-ID: <4AE2EC06CC541BC2201D7BC8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <87hdkspad2.fsf@nwalsh.com> References: <87hdkspad2.fsf@nwalsh.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 4, 2005 11:18:17 AM -0500 Norman Walsh wrote: > > I know we're writing an IETF document, but I think there's going to be > a lot of off-the-shelf XML software that understands xsd:dateTimes and > I think it would be a lot better if we defined Date Constructs in > terms of W3C XML Schema Part 2 than RFC 3339. Strongly agree. Also, we have an unresolved issue with historic Livejournal entries, which do not have timezones. XML Schema explains exactly how to handle those. We can have a SHOULD for timezone info, with an explanation of what you lose without that. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Feb 4 12:52:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19202 for ; Fri, 4 Feb 2005 12:52:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HjK5L080340; Fri, 4 Feb 2005 09:45:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HjK2j080339; Fri, 4 Feb 2005 09:45:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14HjKIL080330 for ; Fri, 4 Feb 2005 09:45:20 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from phys-bur-1 ([129.148.9.72]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j14HjDW0005226 for ; Fri, 4 Feb 2005 10:45:19 -0700 (MST) Received: from conversion-daemon.bur-mail1.east.sun.com by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IBE00C01EGOZP@bur-mail1.east.sun.com> (original mail from ndw@nwalsh.com) for atom-syntax@imc.org; Fri, 04 Feb 2005 12:45:18 -0500 (EST) Received: from localhost (vpn-129-150-33-242.Central.Sun.COM [129.150.33.242]) by bur-mail1.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IBE00M8JEN740@bur-mail1.east.sun.com> for atom-syntax@imc.org; Fri, 04 Feb 2005 12:45:18 -0500 (EST) Received: from ndw by localhost with local (Exim 4.44) id 1Cx7Vf-0002k9-UI for atom-syntax@imc.org; Fri, 04 Feb 2005 12:44:47 -0500 X-URL: http://nwalsh.com/ Date: Fri, 04 Feb 2005 12:44:46 -0500 From: Norman Walsh Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: <4203AF2C.2090304@gmx.de> To: Atom Syntax Message-id: <874qgsmd81.fsf@nwalsh.com> MIME-version: 1.0 Content-type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) References: <87hdkspad2.fsf@nwalsh.com> <4203AF2C.2090304@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Julian Reschke was heard to say: | -> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we | may have to profile one of them. In which case I'd prefer to stick | with RFC3339. Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime values and MUST also match the following regular expression: [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?(Z|[\+\-][0-9]{2}:[0-9]{2}) (Expressed for my own testing purposes in XML Schema pattern syntax.) Be seeing you, norm =2D-=20 Norman Walsh | Some disguised deceits counterfeit http://nwalsh.com/ | truth so perfectly that not to be taken | in by them would be an error of | judgment.--La Rochefoucauld --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCA7SOOyltUcwYWjsRAnzfAJ9H8pYVOOnFaNeP3IBToMPWpbX3ZgCeN592 ktuvIavMI4B0prrY1FFPUVk= =G7Hr -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Fri Feb 4 12:53:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19301 for ; Fri, 4 Feb 2005 12:53:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Hkfct080487; Fri, 4 Feb 2005 09:46:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14HkfSd080486; Fri, 4 Feb 2005 09:46:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14Hkd4R080458 for ; Fri, 4 Feb 2005 09:46:40 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 17:46:34 -0000 Received: from p50825F09.dip0.t-ipconnect.de (EHLO [192.168.1.20]) (80.130.95.9) by mail.gmx.net (mp005) with SMTP; 04 Feb 2005 18:46:34 +0100 X-Authenticated: #1915285 Message-ID: <4203B4F9.7070802@gmx.de> Date: Fri, 04 Feb 2005 18:46:33 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Norman Walsh , Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4AE2EC06CC541BC2201D7BC8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <4AE2EC06CC541BC2201D7BC8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > --On February 4, 2005 11:18:17 AM -0500 Norman Walsh wrote: > >>I know we're writing an IETF document, but I think there's going to be >>a lot of off-the-shelf XML software that understands xsd:dateTimes and >>I think it would be a lot better if we defined Date Constructs in >>terms of W3C XML Schema Part 2 than RFC 3339. > > > Strongly agree. > > Also, we have an unresolved issue with historic Livejournal entries, > which do not have timezones. XML Schema explains exactly how to So what does it recommend? > handle those. We can have a SHOULD for timezone info, with an explanation > of what you lose without that. So what is a recipient of a timestampe without TZ info supposed to do with it? Throw it away? Default to UTC? -1 -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 13:13:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20826 for ; Fri, 4 Feb 2005 13:13:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14I5urM082890; Fri, 4 Feb 2005 10:05:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14I5uIq082889; Fri, 4 Feb 2005 10:05:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14I5uVq082871 for ; Fri, 4 Feb 2005 10:05:56 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 61E77155 for ; Fri, 4 Feb 2005 10:05:51 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j14I5mLf017292 for ; Fri, 4 Feb 2005 10:05:50 -0800 (PST) Date: Fri, 04 Feb 2005 10:05:50 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 Message-ID: <492AAAA5AE90D1BD59E8C553@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <4203B4F9.7070802@gmx.de> References: <87hdkspad2.fsf@nwalsh.com> <4AE2EC06CC541BC2201D7BC8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4203B4F9.7070802@gmx.de> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 4, 2005 6:46:33 PM +0100 Julian Reschke wrote: >> Also, we have an unresolved issue with historic Livejournal entries, >> which do not have timezones. XML Schema explains exactly how to > > So what does it recommend? > >> handle those. We can have a SHOULD for timezone info, with an explanation >> of what you lose without that. Treating the datetime value as if it has an uncertainty equal to the maximum possible timezone offset. The other advantage of use XML Schema is that is defines how to order timestamps, which is the main thing we want to do with them. I think the section is pretty clear, and I'm picky about specs: wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Feb 4 13:43:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22680 for ; Fri, 4 Feb 2005 13:43:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14IcG0d085810; Fri, 4 Feb 2005 10:38:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14IcG9x085809; Fri, 4 Feb 2005 10:38:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14IcFUL085801 for ; Fri, 4 Feb 2005 10:38:15 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j14IcFVu014664 for ; Fri, 4 Feb 2005 11:38:15 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00HQVH3QE1@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:38:15 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005V2H3QUK@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:38:14 -0700 (MST) Date: Fri, 04 Feb 2005 10:38:22 -0800 From: Tim Bray Subject: Re: On organization and abstraction In-reply-to: <4203AC82.1000308@franklinmint.fm> To: mint@franklinmint.fm Cc: "Roy T. Fielding" , Atom Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2fb7279fb4ac8fd7d64392ad800ae5a7@gbiv.com> <4203AC82.1000308@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 9:10 AM, Robert Sayre wrote: >> My interest is in simplification, not abstraction. For example, >> the draft wastes a lot of text talking in the abstract about >> various constructs rather than simply defining one element for >> each of those constructs. > > Person, Date, and Text constructs all save space because they avoid > repetitive requirements, and they match up nicely with the Relax NG. > I'm pretty sure the group has agreed to drop Service constructs, and > mnot has already moved atom:id into an element definition for -06. Right, and Brent Simmons, one of the major implementors, published a blog entry talking about how much, as a programmer, he liked the "person" and "link" and so on constructs. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 13:50:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23207 for ; Fri, 4 Feb 2005 13:50:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14IajRV085685; Fri, 4 Feb 2005 10:36:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Iaj0H085684; Fri, 4 Feb 2005 10:36:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14IainR085678 for ; Fri, 4 Feb 2005 10:36:44 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j14IaiVu013586 for ; Fri, 4 Feb 2005 11:36:44 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00HVBH17HH@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:36:44 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005URH17UK@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:36:43 -0700 (MST) Date: Fri, 04 Feb 2005 10:36:52 -0800 From: Tim Bray Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: <4203A4B7.6090109@franklinmint.fm> To: mint@franklinmint.fm Cc: Atom Syntax , Norman Walsh Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <87hdkspad2.fsf@nwalsh.com> <4203A4B7.6090109@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 8:37 AM, Robert Sayre wrote: >> I know we're writing an IETF document, but I think there's going to be >> a lot of off-the-shelf XML software that understands xsd:dateTimes and >> I think it would be a lot better if we defined Date Constructs in >> terms of W3C XML Schema Part 2 than RFC 3339. >> I propose that we change the spec to do so. > > I agree. I was just writing a protocol implementation in Ruby On Rails > (CRUDs very fast, btw). When I got to the part on date formats, I used > xsd:dateTime code that was already done, figuring that's what everyone > else will do. For what it's worth, in Perl and C I use Posix strftime with this as the argument: "%Y-%m-%dT%H:%M:%S-08:00" (the -08 bit because I'm in Pacific time, adjust as appropriate). -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 14:01:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23972 for ; Fri, 4 Feb 2005 14:01:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Irilg086955; Fri, 4 Feb 2005 10:53:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14IrirG086954; Fri, 4 Feb 2005 10:53:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14IrhAd086948 for ; Fri, 4 Feb 2005 10:53:43 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14Irhdt019318 for ; Fri, 4 Feb 2005 11:53:43 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00HWWHTIE1@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:53:43 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005ZBHTIUN@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 11:53:42 -0700 (MST) Date: Fri, 04 Feb 2005 10:53:52 -0800 From: Tim Bray Subject: Pace production and process To: Atom Syntax Message-id: <2f84d518a14f8bb1449921a3e7ddfe73@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT To those of you who have been providing Paces before the deadline, our thanks. This is a reminder that sometime on Monday, Sam is going to do the *last* rev of AtomPubIssuesList before IETF last call. Both Paul and I have 100% confidence in Sam's judgement as to which Paces are well-enough cooked to merit inclusion in the "Currently Under Discussion" list. We're also happy to see some structure building up around the extension-proposal process. It would be really nice for us co-chairs if we could make our consensus call based mostly on what happens next week; I think the debate this week has been really useful, but both the Paces and the individual opinions have been shifting so much that I despair of pulling anything useful consensus-wise out of it. So I'd encourage everyone, once Sam fires the starting gun, to get in there with their +1's and -1's so we know where everyone ended up. And (process note) I will be in Maui from Sunday to Sunday and (hard to believe I know) not thinking very much about syndication technology. So Paul gets to watch the flow by himself. In practical terms, this means it may take us till sometime around the 15th or so to do that last consensus call. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 14:38:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26484 for ; Fri, 4 Feb 2005 14:38:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JLCX0088737; Fri, 4 Feb 2005 11:21:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JLCQW088736; Fri, 4 Feb 2005 11:21:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JLCeM088723 for ; Fri, 4 Feb 2005 11:21:12 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020419210001200gb00ae>; Fri, 4 Feb 2005 19:21:00 +0000 Date: Fri, 4 Feb 2005 12:20:59 -0700 Subject: Re: PaceIconAndImage Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <13E78FF8-76C8-11D9-976E-003065EA6144@geckotribe.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 09:16 AM, Antone Roundy wrote: > On Thursday, January 27, 2005, at 09:08 AM, Antone Roundy wrote: >> Also, why limit this to feed/head, and not entry? > If we ARE going to limit images to feeds, then please, let's change > the name to "logo". If it were "logo", I'd agree it doesn't belong in > entry. > Let me restate this in a way that might lead to action: I have a sneaking suspicion that we're not going to get consensus on allowing image and/or icon in entry. If that's the case, would anyone object to me changing to in the Pace? From owner-atom-syntax@mail.imc.org Fri Feb 4 14:38:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26519 for ; Fri, 4 Feb 2005 14:38:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JRRb1089169; Fri, 4 Feb 2005 11:27:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JRRYl089168; Fri, 4 Feb 2005 11:27:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JRQtk089160 for ; Fri, 4 Feb 2005 11:27:26 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id C3AC6149 for ; Fri, 4 Feb 2005 11:27:19 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j14JRILf017853 for ; Fri, 4 Feb 2005 11:27:19 -0800 (PST) Date: Fri, 04 Feb 2005 11:27:20 -0800 From: Walter Underwood To: "'Atom Syntax'" Subject: RE: Entry order Message-ID: <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <200502040425.CNH01907@ms8.netsolmail.com> References: <200502040425.CNH01907@ms8.netsolmail.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 3, 2005 11:21:50 PM -0500 Bob Wyman wrote: > David Powell wrote: >> It looks like this might have got lost accidently when the >> atom:head element was introduced. Previously Atom 0.3 said [1]: >>> Ordering of the element children of atom:feed element MUST NOT be >>> considered significant. > +1. > The order of entries in an Atom feed should NOT be significant. This > is, I think, a very, very important point to make. -1 Is this a joke? This is like saying that the order of the entries in my mailbox is not significant. Note that ordering a mailbox by date is not the same thing as its native order. Feed order is the only way we have to show the publication order of items in a feed. I just looked at all my subscriptions, and there is only one where the order might not be relevant, a security test for RSS readers. That is clearly not within Atom's charter, so it doesn't count. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Feb 4 14:43:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26915 for ; Fri, 4 Feb 2005 14:43:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JbqtH089841; Fri, 4 Feb 2005 11:37:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JbqOw089840; Fri, 4 Feb 2005 11:37:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JbpPF089831 for ; Fri, 4 Feb 2005 11:37:51 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cx9Gz-0006ja-3S; Fri, 04 Feb 2005 19:37:45 +0000 Message-ID: <4203CF08.5070802@franklinmint.fm> Date: Fri, 04 Feb 2005 14:37:44 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceIconAndImage References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > Let me restate this in a way that might lead to action: I have a > sneaking suspicion that we're not going to get consensus on allowing > image and/or icon in entry. If that's the case, would anyone object to > me changing to in the Pace? That would be bogus a rule. How does it hurt interop to put an image in an entry? Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 14:43:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26936 for ; Fri, 4 Feb 2005 14:43:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JcVMb089894; Fri, 4 Feb 2005 11:38:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JcVlw089891; Fri, 4 Feb 2005 11:38:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14JcURB089865 for ; Fri, 4 Feb 2005 11:38:30 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 19:38:15 -0000 Received: from mnsr-d9b9cd34.pool.mediaWays.net (EHLO [217.185.205.52]) (217.185.205.52) by mail.gmx.net (mp019) with SMTP; 04 Feb 2005 20:38:15 +0100 X-Authenticated: #1915285 Message-ID: <4203CE26.7040101@gmx.de> Date: Fri, 04 Feb 2005 20:33:58 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4203AF2C.2090304@gmx.de> <874qgsmd81.fsf@nwalsh.com> In-Reply-To: <874qgsmd81.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Julian Reschke was heard to say: > | -> Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we > | may have to profile one of them. In which case I'd prefer to stick > | with RFC3339. > > Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime > values and MUST also match the following regular expression: > > [0-9]{8}T[0-9]{2}:[0-9]{2}:[0-9]{2}(\.[0-9]+)?(Z|[\+\-][0-9]{2}:[0-9]{2}) > > (Expressed for my own testing purposes in XML Schema pattern syntax.) Sounds good to me, except that I would keep the reference to RFC3339 (semantics are the same, but I think RFC3339 is more readable). Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 14:44:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26974 for ; Fri, 4 Feb 2005 14:44:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JcVJG089893; Fri, 4 Feb 2005 11:38:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JcVA6089892; Fri, 4 Feb 2005 11:38:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14JcUO0089872 for ; Fri, 4 Feb 2005 11:38:30 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 19:38:20 -0000 Received: from mnsr-d9b9cd34.pool.mediaWays.net (EHLO [217.185.205.52]) (217.185.205.52) by mail.gmx.net (mp023) with SMTP; 04 Feb 2005 20:38:20 +0100 X-Authenticated: #1915285 Message-ID: <4203CF06.8020707@gmx.de> Date: Fri, 04 Feb 2005 20:37:42 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4AE2EC06CC541BC2201D7BC8@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <4203B4F9.7070802@gmx.de> <492AAAA5AE90D1BD59E8C553@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <492AAAA5AE90D1BD59E8C553@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > --On February 4, 2005 6:46:33 PM +0100 Julian Reschke wrote: > >>>Also, we have an unresolved issue with historic Livejournal entries, >>>which do not have timezones. XML Schema explains exactly how to >> >>So what does it recommend? >> >> >>>handle those. We can have a SHOULD for timezone info, with an explanation >>>of what you lose without that. > > > Treating the datetime value as if it has an uncertainty equal to the > maximum possible timezone offset. The other advantage of use XML Schema Just to clarify: do you see that as as MUST or MAY level requirement? I'm pretty sure that most recipients that actually parse the date will only persist a timestamp (such as ms since the epoch), and not bother with any addutional information. > is that is defines how to order timestamps, which is the main thing > we want to do with them. > > I think the section is pretty clear, and I'm picky about specs: > > As far as I am concerned, the problem with xsd:dateTime is that it includes features (such as the aforementioned TZ uncertainty) that most recipients aren't prepared to handle. So, we need to 1) either subset it so that that syntax is not allowed, or 2) define what recipients should do with these timestamps. I'm -1 on option 2). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 14:51:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27376 for ; Fri, 4 Feb 2005 14:51:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Jjje3090681; Fri, 4 Feb 2005 11:45:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JjjTS090680; Fri, 4 Feb 2005 11:45:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Jjjva090652 for ; Fri, 4 Feb 2005 11:45:45 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j14Jicqv002075; Fri, 4 Feb 2005 14:44:54 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNK42464 (AUTH bob@wyman.us); Fri, 4 Feb 2005 14:44:37 -0500 (EST) Message-Id: <200502041944.CNK42464@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , "'Roy T. Fielding'" Cc: "'Tim Bray'" , "'Atom Syntax'" Subject: PaceHeadless +1 Date: Fri, 4 Feb 2005 14:40:39 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <4203AC82.1000308@franklinmint.fm> Thread-Index: AcUK37iKy4byMFrrSxmTzP9YGJ3L1AADGr3g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > Now that you've written PaceRemoveHeadElement [or, PaceHeadless]... >(Note to Bob: it still does what you want), I think that is what > will probably happen. As long as we can put the feed metadata into an Entry document or instance of an entry I'm happy. I don't care what the tag is called. I simply need to have an entry free and in the wild while still being able to describe the feed from which it was cut. Atom over XMPP, aggregated feeds ala PubSub or as search results, etc. even many forms of archiving will work fine if PaceHeadless is accepted. Note: The proposal in PaceHeadless is essentially what I was originally proposing back in the summer. (i.e. feed meta-data would be "inherited" by entries unless that inheritance was explicitly over-ridden by the presence of a or element in the entry.) You may remember that after a great deal of discussion the whole idea of hierarchy, inheritance, and other similar metaphors was rejected as too complicated. I'm pleased if we have now come to the conclusion that hierarchy and "inheritance" from parent elements is a reasonable thing to specify. However, I'm concerned that it seems like we've gotten to this point rather casually and without as much discussion as we had when the group originally rejected the idea. On the other hand, I think disagreed with the earlier group consensus and think that this is where we should be. So, I won't shoot myself in the foot by complaining any more. bob wyman From owner-atom-syntax@mail.imc.org Fri Feb 4 14:53:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27537 for ; Fri, 4 Feb 2005 14:53:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JiQTT090380; Fri, 4 Feb 2005 11:44:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14JiQp7090379; Fri, 4 Feb 2005 11:44:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14JiP1R090372 for ; Fri, 4 Feb 2005 11:44:25 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j14JiNVu004449 for ; Fri, 4 Feb 2005 12:44:23 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00HYLK5YHH@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 12:44:23 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005KLK5YUN@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 12:44:22 -0700 (MST) Date: Fri, 04 Feb 2005 11:44:31 -0800 From: Tim Bray Subject: Re: Entry order In-reply-to: <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> To: Walter Underwood Cc: "'Atom Syntax'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: > Is this a joke? This is like saying that the order of the entries in my > mailbox is not significant. Note that ordering a mailbox by date is not > the same thing as its native order. Except for, Atom entries have a *compulsory* date. So I have no idea what semantics you'd attach to the "natural" order... -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 15:01:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28118 for ; Fri, 4 Feb 2005 15:01:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Jn6iO090971; Fri, 4 Feb 2005 11:49:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Jn61N090970; Fri, 4 Feb 2005 11:49:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Jn6kc090959 for ; Fri, 4 Feb 2005 11:49:06 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050204194900016004ivrue>; Fri, 4 Feb 2005 19:49:00 +0000 Date: Fri, 4 Feb 2005 12:48:58 -0700 Subject: Re: PaceIconAndImage Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4203CF08.5070802@franklinmint.fm> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 12:37 PM, Robert Sayre wrote: > Antone Roundy wrote: >> Let me restate this in a way that might lead to action: I have a >> sneaking suspicion that we're not going to get consensus on allowing >> image and/or icon in entry. If that's the case, would anyone object >> to me changing to in the Pace? > > That would be bogus a rule. How does it hurt interop to put an image > in an entry? Just to be sure this is clear, I am not advocating that limitation--it is imposed by the Pace, and I seem to recall hearing opinions on both sides about whether entries should have images and/or icons. I'd be happy to allow both, though I doubt icons would get used much in entries. I just want to be sure that if we DON'T allow images in entries, we use a name for the element that makes sense to me to limit to the feed level. From owner-atom-syntax@mail.imc.org Fri Feb 4 15:08:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28713 for ; Fri, 4 Feb 2005 15:08:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14K0YgN091656; Fri, 4 Feb 2005 12:00:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14K0YnX091655; Fri, 4 Feb 2005 12:00:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14K0X1j091642; Fri, 4 Feb 2005 12:00:33 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j14JxxGC021469; Fri, 4 Feb 2005 15:00:28 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNK51151 (AUTH bob@wyman.us); Fri, 4 Feb 2005 14:59:59 -0500 (EST) Message-Id: <200502041959.CNK51151@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Paul Hoffman'" , "'Mark Nottingham'" , "'Tim Bray'" Cc: "'Atom WG'" Subject: RE: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 14:56:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: Thread-Index: AcUK4YJO6tOT89RfTe2X0zqW6yqwjAAEK5dQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > In specific, "a complete archive of all entries in a feed" is well > taken care of by our current format; it's just not explicitly called > "an archive". The fact that our IDs are unique over all time means an > archive of all entries that were ever in the main feed is just a > bigger feed; that will work exactly as an archive with no ambiguity > of elements. Although I can't find it specified in the current draft, there used to be a rule that you weren't supposed to use the same atom:id more than once in a single feed. (This rule is enforced by FeedValidator for Atom 0.3 documents... Sam? Mark?) If the prohibition against having more than one entry in a single feed document with the same atom:id is still in effect, (i.e. if you can't have multiple versions of an entry in a single feed document) then you can't use an Atom feed document to archive "all states or versions" of entries as they have been published over time. You would only be able to archive, at best, a single version of each entry (typically the last one published, I think). One alternative might to be provide an explicit relaxation of the rules by saying that for at least archives, what must be unique is a combined "key" constructed by concatenating atom:id + atom:modified. bob wyman From owner-atom-syntax@mail.imc.org Fri Feb 4 15:11:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29310 for ; Fri, 4 Feb 2005 15:11:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14K4X7F091868; Fri, 4 Feb 2005 12:04:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14K4XOV091867; Fri, 4 Feb 2005 12:04:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14K4S7b091849; Fri, 4 Feb 2005 12:04:29 -0800 (PST) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14K4Sdt009681; Fri, 4 Feb 2005 13:04:28 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00HVEL3FE1@edgemail1.Central.Sun.COM>; Fri, 04 Feb 2005 13:04:28 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE0050OL3FUK@mail.sun.net>; Fri, 04 Feb 2005 13:04:27 -0700 (MST) Date: Fri, 04 Feb 2005 12:04:36 -0800 From: Tim Bray Subject: Re: Call for final Paces for consideration: deadline imminent In-reply-to: <200502041959.CNK51151@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Mark Nottingham'" , "'Paul Hoffman'" , "'Atom WG'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200502041959.CNK51151@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 11:56 AM, Bob Wyman wrote: > Although I can't find it specified in the current draft, there used > to be a rule that you weren't supposed to use the same atom:id more > than > once in a single feed. (This rule is enforced by FeedValidator for > Atom 0.3 > documents... Sam? Mark?) Sounds like a bug to me. I can't see any reason to rule this out. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 15:36:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02223 for ; Fri, 4 Feb 2005 15:36:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KOxVt094069; Fri, 4 Feb 2005 12:24:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14KOxjS094068; Fri, 4 Feb 2005 12:24:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14KOvLp094047 for ; Fri, 4 Feb 2005 12:24:58 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 04 Feb 2005 20:24:51 -0000 Received: from mnsr-d9b9cd6c.pool.mediaWays.net (EHLO [217.185.205.108]) (217.185.205.108) by mail.gmx.net (mp009) with SMTP; 04 Feb 2005 21:24:51 +0100 X-Authenticated: #1915285 Message-ID: <4203D3D5.9070001@gmx.de> Date: Fri, 04 Feb 2005 20:58:13 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Walter Underwood , "'Atom Syntax'" Subject: Re: Entry order References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: > >> Is this a joke? This is like saying that the order of the entries in my >> mailbox is not significant. Note that ordering a mailbox by date is not >> the same thing as its native order. > > > Except for, Atom entries have a *compulsory* date. So I have > no idea what semantics you'd attach to the "natural" order... -Tim Nit: they want have an ordering anymore if we allow "updated" dates with missing timezone information (i.e., dates with a 24h uncertainty). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Fri Feb 4 15:38:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02320 for ; Fri, 4 Feb 2005 15:38:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KTUap094354; Fri, 4 Feb 2005 12:29:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14KTUIP094353; Fri, 4 Feb 2005 12:29:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KTEcU094329; Fri, 4 Feb 2005 12:29:14 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502041959.CNK51151@ms8.netsolmail.com> References: <200502041959.CNK51151@ms8.netsolmail.com> Date: Fri, 4 Feb 2005 12:29:11 -0800 To: , "'Mark Nottingham'" , "'Tim Bray'" From: Paul Hoffman Subject: RE: Call for final Paces for consideration: deadline imminent Cc: "'Atom WG'" Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:56 PM -0500 2/4/05, Bob Wyman wrote: > Although I can't find it specified in the current draft, there used >to be a rule that you weren't supposed to use the same atom:id more than >once in a single feed. The current draft says: 5.8 "atom:id" Element The "atom:id" element is an Identity construct that conveys a permanent, universally unique identifier for an entry. atom:entry elements MUST contain exactly one atom:id element. That means that you're not allowed to sue the same atom:id in any two entries, ever. > If the prohibition against having more than one entry in a single >feed document with the same atom:id is still in effect, Yes.... > (i.e. if you can't >have multiple versions of an entry in a single feed document) then you can't >use an Atom feed document to archive "all states or versions" of entries as >they have been published over time. You would only be able to archive, at >best, a single version of each entry (typically the last one published, I >think). The requirement in the charter is: * a complete archive of all entries in a feed Your proposal expands that significantly. If you feel a need for that (quite different) kind of archive, you can propose an extension. > One alternative might to be provide an explicit relaxation of the >rules by saying that for at least archives, what must be unique is a >combined "key" constructed by concatenating atom:id + atom:modified. We don't need to define "archive" in the core format spec, certainly not in a way that will be confusing to people who only care about entries and normal feeds. That's what extensions are for. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Feb 4 15:51:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03236 for ; Fri, 4 Feb 2005 15:51:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KheoK095172; Fri, 4 Feb 2005 12:43:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14KheS3095171; Fri, 4 Feb 2005 12:43:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14KhbVW095155 for ; Fri, 4 Feb 2005 12:43:39 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 04 Feb 2005 20:43:31 -0000 Received: from dsl-082-083-163-156.arcor-ip.net (EHLO helix) (82.83.163.156) by mail.gmx.net (mp002) with SMTP; 04 Feb 2005 21:43:31 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Paul Hoffman Cc: atom-syntax@imc.org Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 04 Feb 2005 21:43:33 +0100 Message-ID: <421ddde3.111474203@smtp.bjoern.hoehrmann.de> References: <200502041959.CNK51151@ms8.netsolmail.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Paul Hoffman wrote: >> Although I can't find it specified in the current draft, there used >>to be a rule that you weren't supposed to use the same atom:id more than >>once in a single feed. > >The current draft says: > >5.8 "atom:id" Element > > The "atom:id" element is an Identity construct that conveys a > permanent, universally unique identifier for an entry. atom:entry > elements MUST contain exactly one atom:id element. > >That means that you're not allowed to sue the same atom:id in any two >entries, ever. It does not mean that once cannot have multiple versions of the same entry in a feed (or duplicate entries for that matter). -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Fri Feb 4 15:51:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03261 for ; Fri, 4 Feb 2005 15:51:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KiI2v095228; Fri, 4 Feb 2005 12:44:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14KiIUn095227; Fri, 4 Feb 2005 12:44:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14KiHWq095206; Fri, 4 Feb 2005 12:44:17 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 503BF51A30; Fri, 4 Feb 2005 15:44:10 -0500 (EST) In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" , , "'Tim Bray'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 12:44:07 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 4, 2005, at 12:29 PM, Paul Hoffman wrote: > At 2:56 PM -0500 2/4/05, Bob Wyman wrote: >> Although I can't find it specified in the current draft, there used >> to be a rule that you weren't supposed to use the same atom:id more >> than >> once in a single feed. > > The current draft says: > > 5.8 "atom:id" Element > > The "atom:id" element is an Identity construct that conveys a > permanent, universally unique identifier for an entry. atom:entry > elements MUST contain exactly one atom:id element. > > That means that you're not allowed to sue the same atom:id in any two > entries, ever. I don't read it that way, although I understand how you might infer that; there's too much wiggle room in the current text for that intent to be clear. I.e., just because it's a "permanent, universally unique identifier" doesn't mean you're not able to use it twice to talk about a single entry; to RDF people, this will seem quite natural. If you want to only see one instance of an atom:id's content in the set of all entries ever published in any feed, you need to say that explicitly. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 16:08:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04960 for ; Fri, 4 Feb 2005 16:08:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14L1I8J096544; Fri, 4 Feb 2005 13:01:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14L1ImG096543; Fri, 4 Feb 2005 13:01:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14L1HEU096490 for ; Fri, 4 Feb 2005 13:01:18 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j14L0VTd020104; Fri, 4 Feb 2005 21:00:47 GMT In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-6-394612382; protocol="application/pkcs7-signature" Message-Id: <31e339c0c35b2f8de4ed159420173b53@mac.com> Cc: "'Atom WG'" From: Graham Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 21:00:30 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-6-394612382 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: > I.e., just because it's a "permanent, universally unique identifier" > doesn't mean you're not able to use it twice to talk about a single > entry; I disagree, as I've said before. The only literal interpretation is that you can't serve the same entry twice with the same id. We know it doesn't mean that, but the spec just doesn't define in which axis "unique" is meant to apply. Graham --Apple-Mail-6-394612382 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA0MjEwMDMxWjAjBgkqhkiG9w0BCQQxFgQUA4MJv96axDZ4KkSDsphgWB06 2MoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAIQOMRQqvfqrsk9Sl86gGupmf G4nkiGjQ/ETcF3IGIc0zE29F2tPdlQhivFBKKO3LIpl8TGR+ddRoybKDUTVwHtjamSAjoDJuO2bH tferQMZmG9YQ0T6bk43tJBurkKlofOgnIa/72uRbDKkBl0HATMRthVmlxqSrKbEFfjVS01/RO2Ad TqVEbcRD9k8zU7jOuWJFPGhWtM02n+BQJpJOxYXwb6bsUTsK9vJn5ekEgIc9mW28gdilxzDACcnf ZiJAdE8DTCWwX86Vh4WAw5Ds0LWyCCJGULKGdyuj0w1XdXEhKFFRcGFGvS4VR8OR0GKKW1WhRENZ ARcuodMCmS4VGAAAAAAAAA== --Apple-Mail-6-394612382-- From owner-atom-syntax@mail.imc.org Fri Feb 4 16:11:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05143 for ; Fri, 4 Feb 2005 16:11:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14L5ppm097051; Fri, 4 Feb 2005 13:05:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14L5pIW097050; Fri, 4 Feb 2005 13:05:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14L5hal096999; Fri, 4 Feb 2005 13:05:47 -0800 (PST) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j14L5gdt016968; Fri, 4 Feb 2005 14:05:42 -0700 (MST) Received: from xpa-fe2 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00H1NNXIHH@edgemail1.Central.Sun.COM>; Fri, 04 Feb 2005 14:05:42 -0700 (MST) Received: from [192.168.1.2] ([154.20.140.182]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE006FYNXH44@mail.sun.net>; Fri, 04 Feb 2005 14:05:42 -0700 (MST) Date: Fri, 04 Feb 2005 13:05:51 -0800 From: Tim Bray Subject: Re: Call for final Paces for consideration: deadline imminent In-reply-to: To: Mark Nottingham Cc: Paul Hoffman , "'Atom WG'" , bob@wyman.us Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200502041959.CNK51151@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote: >> That means that you're not allowed to sue the same atom:id in any two >> entries, ever. > > I don't read it that way, although I understand how you might infer > that; there's too much wiggle room in the current text for that intent > to be clear. > > I.e., just because it's a "permanent, universally unique identifier" > doesn't mean you're not able to use it twice to talk about a single > entry; to RDF people, this will seem quite natural. If you want to > only see one instance of an atom:id's content in the set of all > entries ever published in any feed, you need to say that explicitly. I'm with Mnot on this one. Just because it uniquely identifies an entry, that doesn't mean you can't have two versions of the same entry in a feed. Given that entries can show up in more than one feed, it is clearly the case that software is going to have to deal with multiple entries bearing the same ID in its input stream, so I don't see any reason for ruling them out in a single feed. But, the spec needs to have no wriggle room. Right now it's silent, it should be clear. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 16:13:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05312 for ; Fri, 4 Feb 2005 16:13:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14L6wbH097165; Fri, 4 Feb 2005 13:06:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14L6weV097163; Fri, 4 Feb 2005 13:06:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail03.svc.cra.dublin.eircom.net (mail03.svc.cra.dublin.eircom.net [159.134.118.19]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14L6v3n097132 for ; Fri, 4 Feb 2005 13:06:57 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 55022 messnum 2049361 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 4 Feb 2005 21:06:49 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail03.svc.cra.dublin.eircom.net (qp 55022) with SMTP; 4 Feb 2005 21:06:49 -0000 Message-ID: <4203E3E5.7080805@dehora.net> Date: Fri, 04 Feb 2005 21:06:45 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: Call for final Paces for consideration: deadline imminent References: <200502041959.CNK51151@ms8.netsolmail.com> <421ddde3.111474203@smtp.bjoern.hoehrmann.de> In-Reply-To: <421ddde3.111474203@smtp.bjoern.hoehrmann.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bjoern Hoehrmann wrote: > It does not mean that once cannot have multiple versions of the same > entry in a feed (or duplicate entries for that matter). Conversely it does imply that if you do, you may (and possibly, must) assume that they are the same entry. The problem: there's no easy way to distinguish between entry states and defective id allocation. cheers Bill From owner-atom-syntax@mail.imc.org Fri Feb 4 16:16:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05552 for ; Fri, 4 Feb 2005 16:16:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LALSX097469; Fri, 4 Feb 2005 13:10:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LALTY097468; Fri, 4 Feb 2005 13:10:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LAKFe097461 for ; Fri, 4 Feb 2005 13:10:20 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F3656519F7; Fri, 4 Feb 2005 16:10:19 -0500 (EST) In-Reply-To: <31e339c0c35b2f8de4ed159420173b53@mac.com> References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 13:10:18 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham, the issue here is that the spec can be interpreted in a number of ways, which is not good. You seem to agree with that below, correct? Separately, there's the issue of what it *should* say. Tim and now you say that you have a good idea of what you want it to say; I'd be very interested to see how you'd specify that. Can you suggest some spec text? On Feb 4, 2005, at 1:00 PM, Graham wrote: > On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: > >> I.e., just because it's a "permanent, universally unique identifier" >> doesn't mean you're not able to use it twice to talk about a single >> entry; > > I disagree, as I've said before. The only literal interpretation is > that you can't serve the same entry twice with the same id. We know it > doesn't mean that, but the spec just doesn't define in which axis > "unique" is meant to apply. > > Graham -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 16:17:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05590 for ; Fri, 4 Feb 2005 16:17:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LAdSc097522; Fri, 4 Feb 2005 13:10:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LAdXa097521; Fri, 4 Feb 2005 13:10:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LAcCF097515 for ; Fri, 4 Feb 2005 13:10:39 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxAio-0008TY-JR; Fri, 04 Feb 2005 21:10:34 +0000 Message-ID: <4203E4CA.5020406@franklinmint.fm> Date: Fri, 04 Feb 2005 16:10:34 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Mark Nottingham , "'Atom WG'" Subject: Re: Call for final Paces for consideration: deadline imminent References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> In-Reply-To: <31e339c0c35b2f8de4ed159420173b53@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: > >> I.e., just because it's a "permanent, universally unique identifier" >> doesn't mean you're not able to use it twice to talk about a single >> entry; > > > I disagree, as I've said before. The only literal interpretation is that > you can't serve the same entry twice with the same id. We know it > doesn't mean that, but the spec just doesn't define in which axis > "unique" is meant to apply. Hmm. The things URIs identify can change. What we really want to say is "don't be a bother and produce different entries with the same id" and "don't expect clients to keep separate records of entries with the same id". We should probably be more worried about bad implementions totally missing the point of "identifiers", than about good implementations with sophisticated notions of versioning and identifiers. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 16:27:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06969 for ; Fri, 4 Feb 2005 16:27:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LIui4098231; Fri, 4 Feb 2005 13:18:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LIuXR098230; Fri, 4 Feb 2005 13:18:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LIu9Q098224 for ; Fri, 4 Feb 2005 13:18:56 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxAqq-00005R-Qi; Fri, 04 Feb 2005 21:18:52 +0000 Message-ID: <4203E6BC.8090009@franklinmint.fm> Date: Fri, 04 Feb 2005 16:18:52 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax , Norman Walsh Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <4203A4B7.6090109@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > On Feb 4, 2005, at 8:37 AM, Robert Sayre wrote: > >> >> I agree. I was just writing a protocol implementation in Ruby On Rails >> (CRUDs very fast, btw). When I got to the part on date formats, I used >> xsd:dateTime code that was already done, figuring that's what everyone >> else will do. > > > For what it's worth, in Perl and C I use Posix strftime with this as the > argument: > > "%Y-%m-%dT%H:%M:%S-08:00" > I was parsing, but one of the bad things about Ruby On Rails is that you don't need to learn Ruby to use it. I have three working apps done and I think I've written like 150 lines of Ruby in my life. So, I just tried the standard library's Date.parse() function, which applies all sorts of grubby heuristics. Worked fine. That's probably similar to what most people in scripting land will do, so I guess the difference between XSD and RFC 3339 isn't a big deal from the that point of view. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 16:43:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09569 for ; Fri, 4 Feb 2005 16:43:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LUX87099021; Fri, 4 Feb 2005 13:30:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LUX9v099020; Fri, 4 Feb 2005 13:30:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LUXuV099004 for ; Fri, 4 Feb 2005 13:30:33 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 5CC7D168 for ; Fri, 4 Feb 2005 13:30:28 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j14LUPLf018459 for ; Fri, 4 Feb 2005 13:30:27 -0800 (PST) Date: Fri, 04 Feb 2005 13:30:27 -0800 From: Walter Underwood To: "'Atom Syntax'" Subject: Re: Entry order Message-ID: In-Reply-To: References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 4, 2005 11:44:31 AM -0800 Tim Bray wrote: > On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote: > >> Is this a joke? This is like saying that the order of the entries in my >> mailbox is not significant. Note that ordering a mailbox by date is not >> the same thing as its native order. > > Except for, Atom entries have a *compulsory* date. So I have no > idea what semantics you'd attach to the "natural" order... -Tim Order the publisher wants to present them in. Conventionally, most recently published first. Entries may be updated without being reordered. If clients are told to ignore the order, and given only an updated timestamp, there is no way to show "most recent headlines", which is the primary purpose of the whole family of RSS formats. Right now, you can shuffle the entries and Atom says it is the same feed. Either we need a published date stamp or we need to honor the order. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Feb 4 16:48:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09840 for ; Fri, 4 Feb 2005 16:48:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LdAE7099496; Fri, 4 Feb 2005 13:39:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LdAbS099495; Fri, 4 Feb 2005 13:39:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ld9YC099486 for ; Fri, 4 Feb 2005 13:39:09 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 23967 invoked by uid 17064); 4 Feb 2005 21:38:59 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.9.31]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 4 Feb 2005 21:38:59 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8ef1b2823409946960de0e2062ada9de@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 22:38:58 +0100 X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit A really clear way to specify this is to say that an id is a functional relation between an entry and a identity construct. This implies: -An Entry can only have one id. -Different Entries can have the same id. Of course because there is a bit of a confusion as to what is meant by an Entry the above sounds paradoxical. It is a bit like the relation the body of a US citizen has to a social security number. The body of a US citizen at a time has a functional relation to a SS number. Any such body has only one SS number. But because when we eat and breath our bodies change it turns out that different bodies have a relation to the same SS number. The different bodies, are time slices of the same US citizen. The group of these time slices is identified by the social security number. So that the relation between the SS number and set of such citizen slices, namely the relation between a SS number and the citizen is both functional and inverse functional. When this group speaks about an Entry as it appears in the Feed tag:bblfish.net/entry1 ... ... you are really speaking about an entry version. But because when people sit down and write an entry they are looking at the present version of the entry, and this is what they use to identify the sequence of entries that form the unique Entry over time, there is a confusion of what is being talked about. It is a little as if I spoke to someone and identified the body I am seeing at present with the person that body is a temporal part of. So when above I say: -An Entry can only have one id. -Different Entries can have the same id. What we mean is - the Entry Version can only have one id - any two Entry Versions that have the same id are different versions of the same Entry. So now one should define what that type of entry is. And that is simple. It is the Collection of all Entry Versions that have the same id. Henry On 4 Feb 2005, at 22:10, Mark Nottingham wrote: > Graham, the issue here is that the spec can be interpreted in a number > of ways, which is not good. You seem to agree with that below, > correct? > > Separately, there's the issue of what it *should* say. Tim and now you > say that you have a good idea of what you want it to say; I'd be very > interested to see how you'd specify that. Can you suggest some spec > text? > > > On Feb 4, 2005, at 1:00 PM, Graham wrote: > >> On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: >> >>> I.e., just because it's a "permanent, universally unique identifier" >>> doesn't mean you're not able to use it twice to talk about a single >>> entry; >> >> I disagree, as I've said before. The only literal interpretation is >> that you can't serve the same entry twice with the same id. We know >> it doesn't mean that, but the spec just doesn't define in which axis >> "unique" is meant to apply. >> >> Graham > > -- > Mark Nottingham http://www.mnot.net/ > From owner-atom-syntax@mail.imc.org Fri Feb 4 17:13:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12469 for ; Fri, 4 Feb 2005 17:13:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M6Jhj001393; Fri, 4 Feb 2005 14:06:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14M6JH8001392; Fri, 4 Feb 2005 14:06:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M6I1k001333 for ; Fri, 4 Feb 2005 14:06:18 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j14M4vi7003924; Fri, 4 Feb 2005 22:05:08 GMT In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7-398479379; protocol="application/pkcs7-signature" Message-Id: <7265e8ba2fb26f0caf40a001a72ac321@mac.com> Cc: "'Atom WG'" From: Graham Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 22:04:57 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-7-398479379 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote: > Separately, there's the issue of what it *should* say. Tim and now you > say that you have a good idea of what you want it to say; I'd be very > interested to see how you'd specify that. Can you suggest some spec > text? As I suggested a couple of days ago: Any two versions of the same entry must use the same id, [which requires that all characters are the same]. Any two different entries must have different ids, [which requires that at least one character is different]." Graham --Apple-Mail-7-398479379 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA0MjIwNDU4WjAjBgkqhkiG9w0BCQQxFgQU+l327mBy7LAjcmX54wv8KdPQ tTwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAs/Lrq870D2/Id5s/fd4UJsRn jPekiWW5rW2CcKRn+gsxjkVaVuGnuGnatzSWJgXeOjQGLmkEImWBIUSTRzx2wpbRYV0pUNFtxwn5 5SkE3tzwHfjVqYJFPV6KhZB9Jp4sj2XccYP+qe+Dw+c9/GLGYJF+jITTLmH2PrVQrDWx39EojVjx ZpEb1/KSH9rXd1swQyqWOO2dySEmyXHixVW2coEveCqtIIRsNu+aIrCG1ReZbAvTvbTlnPkqiG4O 67NIsUCDh1ZVc6ZPQ4tqvzvpCYsAG25dxwnSOm34V4WmyL1SZ6IXR7OOJm+adKXtlX4ws9g5gtUe w2uruw7R1iyaxAAAAAAAAA== --Apple-Mail-7-398479379-- From owner-atom-syntax@mail.imc.org Fri Feb 4 17:15:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12589 for ; Fri, 4 Feb 2005 17:15:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M9I0L001520; Fri, 4 Feb 2005 14:09:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14M9Iem001519; Fri, 4 Feb 2005 14:09:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M9H2g001513 for ; Fri, 4 Feb 2005 14:09:17 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 2DA2451A75; Fri, 4 Feb 2005 17:09:15 -0500 (EST) In-Reply-To: <7265e8ba2fb26f0caf40a001a72ac321@mac.com> References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> <7265e8ba2fb26f0caf40a001a72ac321@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <6e522f2bd5f429504b49d69822117cdc@mnot.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 14:09:15 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit The term "version" seems out of place here. What you're saying, in effect, is that the ID acts as a hash of entry's content, correct? If, so, what value does it bring? On Feb 4, 2005, at 2:04 PM, Graham wrote: > On 4 Feb 2005, at 9:10 pm, Mark Nottingham wrote: > >> Separately, there's the issue of what it *should* say. Tim and now >> you say that you have a good idea of what you want it to say; I'd be >> very interested to see how you'd specify that. Can you suggest some >> spec text? > > As I suggested a couple of days ago: > > Any two versions of the same entry must use the same id, [which > requires that all characters are the same]. Any two different entries > must have different ids, [which requires that at least one character > is different]." > > Graham -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 17:16:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12637 for ; Fri, 4 Feb 2005 17:16:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M4vCf001296; Fri, 4 Feb 2005 14:04:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14M4vJx001295; Fri, 4 Feb 2005 14:04:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M4q4t001280; Fri, 4 Feb 2005 14:04:52 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxBZH-0000xt-FR; Fri, 04 Feb 2005 22:04:47 +0000 Message-ID: <4203F17F.3050408@franklinmint.fm> Date: Fri, 04 Feb 2005 17:04:47 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Mark Nottingham , Paul Hoffman , "'Atom WG'" , bob@wyman.us Subject: Re: Call for final Paces for consideration: deadline imminent References: <200502041959.CNK51151@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I'm with Mnot on this one. Just because it uniquely identifies an > entry, that doesn't mean you can't have two versions of the same > entry in a feed. ... I don't see any reason for ruling them out in a > single feed. Robert Sayre wrote: > We should probably be more worried about bad implementions totally > missing the point of "identifiers", than about good implementations > with sophisticated notions of versioning and identifiers. With that in mind, I'm going to agree with Graham. What will happen is that super-simple implmentations that don't keep state will show both instances, because they don't bother with GUIDs. Then Graham will get bug reports saying "This feed only has nine entries in Shrook, but ten entries in TrivialServerSideScriptX, why is Shrook so broken?" We need to make that feed invalid, and Graham's life easier. Sophisticated implementations can assert common ancestry with an extension element. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 17:16:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12655 for ; Fri, 4 Feb 2005 17:16:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M8HVW001497; Fri, 4 Feb 2005 14:08:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14M8Hs5001496; Fri, 4 Feb 2005 14:08:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14M8G9B001489 for ; Fri, 4 Feb 2005 14:08:17 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 33C4451A30; Fri, 4 Feb 2005 17:08:15 -0500 (EST) In-Reply-To: <55bebef8e933fd963aa8653cc0082765@textuality.com> References: <63e2637b4f5cde830343778bb9722713@mnot.net> <55bebef8e933fd963aa8653cc0082765@textuality.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceExtendingAtom Date: Fri, 4 Feb 2005 14:08:13 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit It certainly gives the impression that there's a preference; it's like saying "The language of the feed SHOULD be English;" there are lots of options, and we don't require one, but it does call one out. Why is this a normative requirement, and what does adding this sentence bring to the spec? On Feb 3, 2005, at 11:27 PM, Tim Bray wrote: > > On Feb 3, 2005, at 8:17 PM, Mark Nottingham wrote: > >>> This specification describes Atom's XML markup vocabulary. >>> Markup from >>> other vocabularies ("foreign markup") can be used in Atom in >>> a variety of >>> ways. Text Constructs may contain foreign markup which >>> SHOULD be HTML or >>> XHTML. >> >> What does this statement add? Why is HTML or XHTML normatively >> preferred over text, MathML, or any other vocabulary? > > It's not preferred over text, you can say type='TEXT', but since this > is a *text* construct and quite likely to be presented in rows & > columns (title, author, etc) simpler is better, so I'd think the > SHOULD is sensible here. -Tim > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 17:17:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12754 for ; Fri, 4 Feb 2005 17:17:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MD3Hl001837; Fri, 4 Feb 2005 14:13:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MD3Mu001836; Fri, 4 Feb 2005 14:13:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MD2vn001825 for ; Fri, 4 Feb 2005 14:13:02 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <200502042212570140038c96e>; Fri, 4 Feb 2005 22:12:57 +0000 Date: Fri, 4 Feb 2005 15:12:55 -0700 Subject: Re: Call for final Paces for consideration: deadline imminent Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <31e339c0c35b2f8de4ed159420173b53@mac.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 02:00 PM, Graham wrote: > On 4 Feb 2005, at 8:44 pm, Mark Nottingham wrote: >> I.e., just because it's a "permanent, universally unique identifier" >> doesn't mean you're not able to use it twice to talk about a single >> entry; > > I disagree, as I've said before. The only literal interpretation is > that you can't serve the same entry twice with the same id. We know it > doesn't mean that, but the spec just doesn't define in which axis > "unique" is meant to apply. > "3.5 Identity Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent." Sure, if you really want to get nit-picky, this sentence when read in isolation says that the XML which is the parent of the ID construct is the only thing that may ever use this identifier. Taking this nit-pick to its extreme, you could say this means that its a violation to use the same ID for the entry on your hard drive and the entry in RAM, or perhaps even a violation to use the same ID for the entry in RAM across refreshes of the RAM, since different electrons are involved--or maybe even across instants in time, depending on the true nature of the space-time continuum. Obviously, at some point, the nit-picking gets ridiculous. We might resolve the nit-pick with language like this (which is a bit over the top): "An Identity construct is an element whose content conveys an unchanging identifier which MUST be universally unique within Atom Documents to the set of all versions and instantiations of the resource that the construct's parent instantiates." I personally expect people to understand the existing spec text as intended, especially within the context of what follows. For example: When an Atom document is relocated, migrated, syndicated, republished, exported or imported, the content of its Identity construct MUST NOT change. Put another way, an Identity construct pertains to all instantiations of a particular Atom entry or feed; revisions retain the same content in their Identity constructs. This makes it unmistakably clear that we were NOT talking about the ink that formed the specific XML that someone wrote down on their napkin, but "all instantiations" and "revisions". From owner-atom-syntax@mail.imc.org Fri Feb 4 17:23:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13612 for ; Fri, 4 Feb 2005 17:23:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MFZMV002078; Fri, 4 Feb 2005 14:15:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MFZDR002077; Fri, 4 Feb 2005 14:15:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MFYj7002069 for ; Fri, 4 Feb 2005 14:15:34 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxBjb-0001CF-RV; Fri, 04 Feb 2005 22:15:27 +0000 Message-ID: <4203F400.2070202@franklinmint.fm> Date: Fri, 04 Feb 2005 17:15:28 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham CC: Tim Bray , Atom Syntax Subject: Re: PaceExtendingAtom References: <63e2637b4f5cde830343778bb9722713@mnot.net> <55bebef8e933fd963aa8653cc0082765@textuality.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > > It certainly gives the impression that there's a preference; it's like > saying "The language of the feed SHOULD be English;" there are lots of > options, and we don't require one, but it does call one out. > > Why is this a normative requirement, and what does adding this sentence > bring to the spec? TEXT, HTML, and XHTML are preferred because they interoperate. "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Seems right to me. If MathML titles become wildly popular, the spec can be revised later on. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 17:27:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14096 for ; Fri, 4 Feb 2005 17:27:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MKdpp002374; Fri, 4 Feb 2005 14:20:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MKdDi002373; Fri, 4 Feb 2005 14:20:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MKcwg002365 for ; Fri, 4 Feb 2005 14:20:38 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j14MIvDb006666; Fri, 4 Feb 2005 22:18:57 GMT In-Reply-To: <6e522f2bd5f429504b49d69822117cdc@mnot.net> References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> <7265e8ba2fb26f0caf40a001a72ac321@mac.com> <6e522f2bd5f429504b49d69822117cdc@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8-399319361; protocol="application/pkcs7-signature" Message-Id: <789a0390e5fb797e3e5496404dabb5f0@mac.com> Cc: "'Atom WG'" From: Graham Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 22:18:57 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-8-399319361 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote: > The term "version" seems out of place here. What you're saying, in > effect, is that the ID acts as a hash of entry's content, correct? If, > so, what value does it bring? Pardon: >> Any two versions of the same entry must use the same id, [which >> requires that all characters are the same]. Any two different entries >> must have different ids, [which requires that at least one character >> is different]." It says different versions must have the same id. How is that a hash? Graham --Apple-Mail-8-399319361 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA0MjIxODU4WjAjBgkqhkiG9w0BCQQxFgQUFXg59YOzQGXcrpmsMm4KU+SI UpMweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAbJiKJlDgpKQTQs3lh8W5pfFH LA9FAOHYjOWiKFd8b+nXAHHjYw/hil1rSTG5X3nFdCcg1eQCcC+gZZNlTiF4AIEpUTelW27lYAbB Jv57+4mRYeMdpK+Mjp2xjoXPcHbTC845iqooHd/JSSPJHVQA8LHPp5sua8wdEo6r3TI5YfwxzwBd Pdw3hnVzO8c/DwIGCoCUnFlicspe5fU9aXQ2gz5Kcejfa4AcUMl3VI/V6QnNp4DYSjzEKl0451hC aUH6PnyTZLbVczQ3Q0lgv7ANh+2w8y4dcMvoYsASICMuloMQzUt0Ngd8fhznxcHliO3KbXPRE1j7 YQk2SbZmL79lZAAAAAAAAA== --Apple-Mail-8-399319361-- From owner-atom-syntax@mail.imc.org Fri Feb 4 17:29:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14169 for ; Fri, 4 Feb 2005 17:29:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MMPBi002523; Fri, 4 Feb 2005 14:22:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MMPM3002522; Fri, 4 Feb 2005 14:22:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MMOL6002514 for ; Fri, 4 Feb 2005 14:22:24 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020422221901300k7nr3e>; Fri, 4 Feb 2005 22:22:19 +0000 Date: Fri, 4 Feb 2005 15:22:18 -0700 Subject: Re: Call for final Paces for consideration: deadline imminent Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <3AD6E2C1-76FB-11D9-976E-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 02:05 PM, Tim Bray wrote: > On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote: >>> That means that you're not allowed to sue the same atom:id in any >>> two entries, ever. >> >> I don't read it that way, although I understand how you might infer >> that; there's too much wiggle room in the current text for that >> intent to be clear. >> >> I.e., just because it's a "permanent, universally unique identifier" >> doesn't mean you're not able to use it twice to talk about a single >> entry; to RDF people, this will seem quite natural. If you want to >> only see one instance of an atom:id's content in the set of all >> entries ever published in any feed, you need to say that explicitly. > > I'm with Mnot on this one. Just because it uniquely identifies an > entry, that doesn't mean you can't have two versions of the same entry > in a feed. Given that entries can show up in more than one feed, it > is clearly the case that software is going to have to deal with > multiple entries bearing the same ID in its input stream, so I don't > see any reason for ruling them out in a single feed. > > But, the spec needs to have no wriggle room. Right now it's silent, > it should be clear. -Tim The following language should make things clear: First, if we want to be able to put multiple revisions of an entry into a single Atom Feed Document (note: I'm talking about a document, not the abstraction called a feed), or multiple portions or versions of a feed into a single Atom Aggregation Document, if such a thing ever comes to exist: "An Atom Document MAY contain multiple versions of the same resource, in which case the content of the Identity construct for each would be identical." Second, if we don't want that to be possible: "An Atom Document MUST NOT contain more than one version of the same resource. Thus, no two resources in a single Atom Document can have the same content in their Identity constructs." From owner-atom-syntax@mail.imc.org Fri Feb 4 17:29:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14200 for ; Fri, 4 Feb 2005 17:29:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MKA2R002349; Fri, 4 Feb 2005 14:20:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MKAL3002348; Fri, 4 Feb 2005 14:20:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MKA4J002333; Fri, 4 Feb 2005 14:20:10 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 4EE4C51A0A; Fri, 4 Feb 2005 17:20:09 -0500 (EST) In-Reply-To: <4203F400.2070202@franklinmint.fm> References: <63e2637b4f5cde830343778bb9722713@mnot.net> <55bebef8e933fd963aa8653cc0082765@textuality.com> <4203F400.2070202@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <7f9156d6a071f526780a56d42630f30e@mnot.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Paul Hoffman , Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceExtendingAtom Date: Fri, 4 Feb 2005 14:20:02 -0800 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Baking this as a normative requirement -- even a SHOULD -- into a standards-track RFC is a bad idea. These formats are not the only interoperable formats on the planet, and in fact they all have interop problems to some degree. In five years, this requirement isn't going to make any sense. I've said my piece on this one; I'm interested in responses to my other questions and points. Cheers, On Feb 4, 2005, at 2:15 PM, Robert Sayre wrote: > Mark Nottingham wrote: >> It certainly gives the impression that there's a preference; it's >> like saying "The language of the feed SHOULD be English;" there are >> lots of options, and we don't require one, but it does call one out. >> Why is this a normative requirement, and what does adding this >> sentence bring to the spec? > > TEXT, HTML, and XHTML are preferred because they interoperate. > > "there may exist valid reasons in particular circumstances to ignore a > particular item, but the full implications must be understood and > carefully weighed before choosing a different course." > > Seems right to me. If MathML titles become wildly popular, the spec > can be revised later on. > > Robert Sayre > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 17:34:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14622 for ; Fri, 4 Feb 2005 17:34:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MT2iu002843; Fri, 4 Feb 2005 14:29:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MT2d2002842; Fri, 4 Feb 2005 14:29:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MT15D002835 for ; Fri, 4 Feb 2005 14:29:01 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1031405wri for ; Fri, 04 Feb 2005 14:28:53 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=N0c7kV25rDMIJoYNF32Y9hmCbH3uT/KIaaNTC6aaObWmNFNU4PRammFeMjOu1duD0rF8P2i3tAlLRLihZOzYVwfrL2guc6tNsS+FUhBTFdz4KflprAmZfM5lies41XYuy1DmNXIX4IRQ3oA4xSEmKPrPt++E0tc8lLLkOjkQ4ow= Received: by 10.54.32.40 with SMTP id f40mr167333wrf; Fri, 04 Feb 2005 14:28:53 -0800 (PST) Received: by 10.54.18.2 with HTTP; Fri, 4 Feb 2005 14:28:53 -0800 (PST) Message-ID: <540e373205020414287097903f@mail.gmail.com> Date: Fri, 4 Feb 2005 16:28:53 -0600 From: "Roger B." Reply-To: "Roger B." To: Walter Underwood Subject: Re: Entry order Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > If clients are told to ignore the order, and given only an updated timestamp, > there is no way to show "most recent headlines"... At a single moment within a feedstream, sure... but the next time an entry is added to that feed, I'll have no problem letting the user know that this is new stuff. > Either we need a published date stamp or we need to honor the order. Maybe I've missed something amidst the chao-- enthusiastic array of Paces lately, but don't we *have* a published date? -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Fri Feb 4 17:39:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14953 for ; Fri, 4 Feb 2005 17:39:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MVHgo002989; Fri, 4 Feb 2005 14:31:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MVHmH002988; Fri, 4 Feb 2005 14:31:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MVHOW002981 for ; Fri, 4 Feb 2005 14:31:17 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050204223111014003g1vle>; Fri, 4 Feb 2005 22:31:11 +0000 Date: Fri, 4 Feb 2005 15:31:10 -0700 Subject: Re: Call for final Paces for consideration: deadline imminent Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4203F17F.3050408@franklinmint.fm> Message-Id: <7842FE0A-76FC-11D9-976E-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 03:04 PM, Robert Sayre wrote: > Sophisticated implementations can assert common ancestry with an > extension element. Could you elaborate a little on this. If we forbid putting two revisions of the same entry into a single document (unless you change the ID between revisions...please, I hope that's not what's being suggested), then what could an extension do? From owner-atom-syntax@mail.imc.org Fri Feb 4 17:40:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14979 for ; Fri, 4 Feb 2005 17:40:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MWuSG003127; Fri, 4 Feb 2005 14:32:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MWuXk003126; Fri, 4 Feb 2005 14:32:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MWtj9003119 for ; Fri, 4 Feb 2005 14:32:55 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 9A72151A20; Fri, 4 Feb 2005 17:32:54 -0500 (EST) In-Reply-To: <789a0390e5fb797e3e5496404dabb5f0@mac.com> References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> <7265e8ba2fb26f0caf40a001a72ac321@mac.com> <6e522f2bd5f429504b49d69822117cdc@mnot.net> <789a0390e5fb797e3e5496404dabb5f0@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34d085bdc3adc298d69983e3c18cc858@mnot.net> Content-Transfer-Encoding: 7bit Cc: "'Atom WG'" X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 14:32:48 -0800 To: Graham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit When you talk about characters being the same or different, are you saying in the entry, or in the id? On Feb 4, 2005, at 2:18 PM, Graham wrote: > On 4 Feb 2005, at 10:09 pm, Mark Nottingham wrote: > >> The term "version" seems out of place here. What you're saying, in >> effect, is that the ID acts as a hash of entry's content, correct? >> If, so, what value does it bring? > > Pardon: > >>> Any two versions of the same entry must use the same id, [which >>> requires that all characters are the same]. Any two different >>> entries must have different ids, [which requires that at least one >>> character is different]." > > It says different versions must have the same id. How is that a hash? > > Graham > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 17:41:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15113 for ; Fri, 4 Feb 2005 17:41:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ma9gQ003286; Fri, 4 Feb 2005 14:36:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Ma90r003285; Fri, 4 Feb 2005 14:36:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ma8tc003274 for ; Fri, 4 Feb 2005 14:36:09 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so813298rng for ; Fri, 04 Feb 2005 14:36:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=pljuQN2SnmY+ttq+5LijIPp6Zcaon2edkjLpsGb6KVkaxCh0I9EJAEm8520juIv3fPKzgnbOBfJWQcw+HbfOXAUQhtG4Lvw8QBh/AHMmZLV5Grjx/DYfHkTBGxIdqXuba7aLPTfq10ANs0e12gLidIjW/5cNv/EkNGQwc+EJoco= Received: by 10.38.71.50 with SMTP id t50mr269586rna; Fri, 04 Feb 2005 14:36:03 -0800 (PST) Received: by 10.38.151.18 with HTTP; Fri, 4 Feb 2005 14:36:03 -0800 (PST) Message-ID: <3f1451f50502041436511a547a@mail.gmail.com> Date: Fri, 4 Feb 2005 17:36:03 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Sam Ruby Subject: Re: PaceRemoveVersionAttr Cc: Norman Walsh , Atom Syntax In-Reply-To: <4202C840.5050003@intertwingly.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <878y658hqj.fsf@nwalsh.com> <4202C840.5050003@intertwingly.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 03 Feb 2005 19:56:32 -0500, Sam Ruby wrote: > For me, I'd like the comfort of knowing that a V1.0 feed will continue > to be valid with respect to future versions of the specifications, and > that tools written to consume V1.0 feeds will continue to work with > subsequent versions of the specification. > > RSS 0.9x (including 2.0) is evidence that the former is possible (I can > cite some minor incompatibilities, but these are merely exceptions that > prove the rule). I do believe that the latter is also possible. > > Without ever changing the namespace. +1 And +1 to PaceRemoveVersionAttr, particularly in light of Atom being a Must Understand vocabulary. -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Fri Feb 4 17:48:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15435 for ; Fri, 4 Feb 2005 17:48:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Me3M5003496; Fri, 4 Feb 2005 14:40:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Me3Sb003495; Fri, 4 Feb 2005 14:40:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Me2D4003481 for ; Fri, 4 Feb 2005 14:40:03 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j14Mct2Z011322; Fri, 4 Feb 2005 22:38:55 GMT In-Reply-To: <34d085bdc3adc298d69983e3c18cc858@mnot.net> References: <200502041959.CNK51151@ms8.netsolmail.com> <31e339c0c35b2f8de4ed159420173b53@mac.com> <7265e8ba2fb26f0caf40a001a72ac321@mac.com> <6e522f2bd5f429504b49d69822117cdc@mnot.net> <789a0390e5fb797e3e5496404dabb5f0@mac.com> <34d085bdc3adc298d69983e3c18cc858@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-9-400517510; protocol="application/pkcs7-signature" Message-Id: <46e156df2f7de4fbd4529040128b7039@mac.com> Cc: "'Atom WG'" From: Graham Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 22:38:55 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-9-400517510 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 4 Feb 2005, at 10:32 pm, Mark Nottingham wrote: > When you talk about characters being the same or different, are you > saying in the entry, or in the id? Oh, right. The id. That would be clear if the things in brackets were expanded (since "same" and "different" ids also need defining). Graham --Apple-Mail-9-400517510 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA0MjIzODU2WjAjBgkqhkiG9w0BCQQxFgQUsBrQnPVdJ2IFoXXVA1geC3X1 sR0weAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAoSkBlnoFamnuuRxqs3qipzv4 WQjAFPi7Qcf42ekP9DAIy9FAZsdVuzF5NPtJGFOvLzlFIF3feIS3UOgylTO0HiySSmZphJ0DZNOY Eeh4MUxP3VeJQD3EXzZIDzhbSVadJlmLoPMyi0+SZhpRYfGgQrgU5wd6GT/gnMcQxBGAqdotK9Lh vkLU+aG6BiN8KcJmcpp89qEEWCTE0mOo+HsNghrZhYhP4B8ycczXsW6guzXj2Xzit3l6PzBc1WE/ pshGe2/1hsSmkpnocuBxsnuX7jsbdTsNfKVylgR1Wq03434toWtK4qqHRMFLjkBdo8jQVfrqMzo7 F9E+5X0lMfiWuAAAAAAAAA== --Apple-Mail-9-400517510-- From owner-atom-syntax@mail.imc.org Fri Feb 4 17:53:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15877 for ; Fri, 4 Feb 2005 17:53:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MlG4I003945; Fri, 4 Feb 2005 14:47:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MlGNG003944; Fri, 4 Feb 2005 14:47:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ml51i003902; Fri, 4 Feb 2005 14:47:10 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> Date: Fri, 4 Feb 2005 13:26:08 -0800 To: Tim Bray , Mark Nottingham From: Paul Hoffman Subject: Re: Call for final Paces for consideration: deadline imminent Cc: "'Atom WG'" , bob@wyman.us Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:05 PM -0800 2/4/05, Tim Bray wrote: >On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote: > >>>That means that you're not allowed to sue the same atom:id in any >>>two entries, ever. >> >>I don't read it that way, although I understand how you might infer >>that; there's too much wiggle room in the current text for that >>intent to be clear. >> >>I.e., just because it's a "permanent, universally unique >>identifier" doesn't mean you're not able to use it twice to talk >>about a single entry; to RDF people, this will seem quite natural. >>If you want to only see one instance of an atom:id's content in the >>set of all entries ever published in any feed, you need to say that >>explicitly. > >I'm with Mnot on this one. So am I; I should have sad "...in any two different entries, ever". And an archive of a feed can have the entry many times, no problem. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Fri Feb 4 17:54:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15899 for ; Fri, 4 Feb 2005 17:54:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MlQ5H003967; Fri, 4 Feb 2005 14:47:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MlQqi003966; Fri, 4 Feb 2005 14:47:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MlQ3J003958 for ; Fri, 4 Feb 2005 14:47:26 -0800 (PST) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02b.bea.com [172.16.120.56]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j14MlL27001572; Fri, 4 Feb 2005 14:47:21 -0800 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Feb 2005 14:47:21 -0800 Received: from [172.16.1.2] ([192.168.114.209]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Feb 2005 14:47:19 -0800 In-Reply-To: <42039FAB.3080603@dehora.net> References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceProfile - new Date: Fri, 4 Feb 2005 14:47:13 -0800 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 04 Feb 2005 22:47:19.0458 (UTC) FILETIME=[7B81D820:01C50B0B] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.2.4.6 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j14MlQ3J003959 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Hmm. I'm thinking of profiles as fairly coarse-grained things; so coarse-grained, it wouldn't make sense to mix-and-match them in a single document (or, if you do, you either don't use a profile, or you invent a new one). I.e., does it make sense to mix a "stock quote" entry with a "systems monitoring" or "blog" entry? How would a UA present this? On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote: > Mark Nottingham wrote: >> Bill, >> I'm sorry, I don't think I get what you're saying; the words all make >> sense, but I don't know how you got here. >> [../] >> The Pace doesn't place any requirements on Atom Processors WRT >> @profile; it's just an advisory flag that tells it what kinds of >> metadata it can count on appearing in the feed. > > Ok, I'll calm down and try again. > > If the advisory @profile scopes at the level of the feed, I think > that's too broad a scope. It needs to scope at the level of the entry, > or it's liable to becomes meaningless when entries are mixed and > matched. I can barely figure out how to class individual entries, > never mind entire feeds. Maybe there's a use case I'm not getting. -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Fri Feb 4 17:55:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15953 for ; Fri, 4 Feb 2005 17:55:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MlAtG003931; Fri, 4 Feb 2005 14:47:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14MlAro003928; Fri, 4 Feb 2005 14:47:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr4.netsolmail.com (omr4.netsolmail.com [216.168.230.140]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ml7Bs003903; Fri, 4 Feb 2005 14:47:08 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr4.netsolmail.com (8.12.10/8.12.10) with ESMTP id j14Ml5qn020383; Fri, 4 Feb 2005 17:47:05 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNL09336 (AUTH bob@wyman.us); Fri, 4 Feb 2005 17:47:03 -0500 (EST) Message-Id: <200502042247.CNL09336@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Paul Hoffman'" , "'Mark Nottingham'" , "'Tim Bray'" Cc: "'Atom WG'" Subject: RE: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 17:43:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUK+EVBrbom4zp0SaWmbzOHas1SNQAEhDvA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > That means that you're not allowed to [use] the same atom:id in any > two entries, ever. We have atom:modified in order to indicate that an instance is a modified version of a previously published entry. The linkage between the two instances of the entry is that they share a common atom:id. Forcing each instance of each entry to have a unique id would make it impossible for us to do what users expect us to do in one aspect of "duplicate" detection. i.e. Users don't normally want to see ever state of an entry as it develops over time, what they typically want to see is the most recent state of the entry. To provide this, we need a way to link together the various versions or states of the entry -- that is done with atom:id. Priority of the versions is determined using atom:modified... bob wyman From owner-atom-syntax@mail.imc.org Fri Feb 4 17:56:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16009 for ; Fri, 4 Feb 2005 17:56:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Mo8qx004118; Fri, 4 Feb 2005 14:50:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Mo8JK004117; Fri, 4 Feb 2005 14:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Mo8ad004111 for ; Fri, 4 Feb 2005 14:50:08 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxCH6-0001mE-12; Fri, 04 Feb 2005 22:50:04 +0000 Message-ID: <4203FC1C.80209@franklinmint.fm> Date: Fri, 04 Feb 2005 17:50:04 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Call for final Paces for consideration: deadline imminent References: <7842FE0A-76FC-11D9-976E-003065EA6144@geckotribe.com> In-Reply-To: <7842FE0A-76FC-11D9-976E-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Friday, February 4, 2005, at 03:04 PM, Robert Sayre wrote: > >> Sophisticated implementations can assert common ancestry with an >> extension element. > > Could you elaborate a little on this. If we forbid putting two > revisions of the same entry into a single document (unless you change > the ID between revisions...please, I hope that's not what's being > suggested), then what could an extension do? > It's a trade-off. Make atom:id confusing to implementors and have poor interop with simple code, or require more complex code to jump through hoops. So, my suggestion is exactly what you'd feared. You could do an end run on the problem and pick a different delivery mechanism. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 17:56:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16027 for ; Fri, 4 Feb 2005 17:56:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Mnj3d004073; Fri, 4 Feb 2005 14:49:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Mnjav004072; Fri, 4 Feb 2005 14:49:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14MniRe004059; Fri, 4 Feb 2005 14:49:44 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 8BE50519F7; Fri, 4 Feb 2005 17:49:43 -0500 (EST) In-Reply-To: References: <200502041959.CNK51151@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <31be7c4f733f737a1d089300dbaf566f@mnot.net> Content-Transfer-Encoding: 7bit Cc: bob@wyman.us, "'Atom WG'" , Tim Bray X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 14:49:36 -0800 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit OK, so it sounds like this is just down to the slippery topic of defining what an entry is, or coming up with the appropriate weasel words the have the same effect without doing it. I don't envy the editors on this one. Uh-oh... On Feb 4, 2005, at 1:26 PM, Paul Hoffman wrote: > At 1:05 PM -0800 2/4/05, Tim Bray wrote: >> On Feb 4, 2005, at 12:44 PM, Mark Nottingham wrote: >> >>>> That means that you're not allowed to sue the same atom:id in any >>>> two entries, ever. >>> >>> I don't read it that way, although I understand how you might infer >>> that; there's too much wiggle room in the current text for that >>> intent to be clear. >>> >>> I.e., just because it's a "permanent, universally unique identifier" >>> doesn't mean you're not able to use it twice to talk about a single >>> entry; to RDF people, this will seem quite natural. If you want to >>> only see one instance of an atom:id's content in the set of all >>> entries ever published in any feed, you need to say that explicitly. >> >> I'm with Mnot on this one. > > So am I; I should have sad "...in any two different entries, ever". > And an archive of a feed can have the entry many times, no problem. > > --Paul Hoffman, Director > --Internet Mail Consortium > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 18:33:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20079 for ; Fri, 4 Feb 2005 18:33:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NF2Zf006184; Fri, 4 Feb 2005 15:15:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14NF2G4006183; Fri, 4 Feb 2005 15:15:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NF1iJ006172 for ; Fri, 4 Feb 2005 15:15:01 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so980596wra for ; Fri, 04 Feb 2005 15:14:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=J4vB8KOUXF97iAX9C1S3IDEA7Lbu+bqGjQqeIwU64njf7M6k/n1scOfsbeuxNnxDgGxoHOad82bKMZ4wW7jZ7UhkpRKEzYjmJ8scC97UAN8Tqk9CZtpqDhUsdlhlvbTXnlhXFB6bSEULRYok2uJGavpmsK6TF+zB/SLp+7pIjlU= Received: by 10.54.14.37 with SMTP id 37mr68690wrn; Fri, 04 Feb 2005 15:14:56 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 35sm200135wra.2005.02.04.15.14.55; Fri, 04 Feb 2005 15:14:56 -0800 (PST) Message-ID: <420401EC.7030900@gmail.com> Date: Fri, 04 Feb 2005 15:14:52 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceProfile - new References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit It would make sense to mix "syndication", "archive", "aggregation", etc. In other words, some profiles would make sense to mix together. Entry-scoped profile makes a LOT of sense. @profile attribute on the feed level applies only to the feed and is used to identify the collection(s) of metadata elements used in the feed. @profile attribute on the entry level applies only to the entry and is used to identify the collection(s) of metadata elements used in the entry. ... ... ... ... Other than helping to identify the collection of metadata elements, another nice about this approach is that it allows the producer of the feed to explicitly indicate the purpose of the feed. Feeds that are intended for archiving use can be handled differently than feeds that are intended for syndication. Entries that use a blog profile can be handled differently than entries used, for instance, to express CAP Alert information, etc. As for profiles that don't make sense to mix and match, leave the decision about whether to mix and match up to the producer of the feed/entry. If the UA detects that a feed/entry uses a combination of profiles that are contradictory, the UA can choose to either reject the item or choose to ignore one or both of the profiles and attempt to deal with the entry by falling back on the default core metadata elements. If a profile is indicated that the UA does not understand, the UA could safely ignore the profile and just work off the minimally required core metadata elements. - James M Snell Mark Nottingham wrote: > > Hmm. I'm thinking of profiles as fairly coarse-grained things; so > coarse-grained, it wouldn't make sense to mix-and-match them in a single > document (or, if you do, you either don't use a profile, or you invent a > new one). > > I.e., does it make sense to mix a "stock quote" entry with a "systems > monitoring" or "blog" entry? How would a UA present this? > > > On Feb 4, 2005, at 8:15 AM, Bill de hÓra wrote: > >> Mark Nottingham wrote: >> >>> Bill, >>> I'm sorry, I don't think I get what you're saying; the words all make >>> sense, but I don't know how you got here. >>> [../] >>> The Pace doesn't place any requirements on Atom Processors WRT >>> @profile; it's just an advisory flag that tells it what kinds of >>> metadata it can count on appearing in the feed. >> >> >> Ok, I'll calm down and try again. >> >> If the advisory @profile scopes at the level of the feed, I think >> that's too broad a scope. It needs to scope at the level of the entry, >> or it's liable to becomes meaningless when entries are mixed and >> matched. I can barely figure out how to class individual entries, >> never mind entire feeds. Maybe there's a use case I'm not getting. > > > -- > Mark Nottingham Principal Technologist > Office of the CTO BEA Systems > > > From owner-atom-syntax@mail.imc.org Fri Feb 4 18:34:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20191 for ; Fri, 4 Feb 2005 18:34:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NNWc9006767; Fri, 4 Feb 2005 15:23:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14NNWu4006766; Fri, 4 Feb 2005 15:23:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NNWRI006756 for ; Fri, 4 Feb 2005 15:23:32 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050204232327014003gvmje>; Fri, 4 Feb 2005 23:23:27 +0000 Date: Fri, 4 Feb 2005 16:23:26 -0700 Subject: Re: Call for final Paces for consideration: deadline imminent Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote: > "An Identity construct is an element whose content conveys an > unchanging identifier which MUST be universally unique within Atom > Documents to the set of all versions and instantiations of the > resource that the construct's parent instantiates." Okay, getting serious now, there is room for clarification. How about we replace this: > "3.5 Identity Constructs > An Identity construct is an element whose content conveys a permanent, > universally unique identifier for the construct's parent." with this: 3.5 Identity Constructs An Identity construct is an element whose content conveys a permanent, universally unique identifier for the resource (instantiated|described) by the construct's parent element. An Atom Document MAY contain multiple (revisions|versions) of the same resource, in which case the content of the Identity construct for each would be identical. Applications MAY decline to display more than one version of each resource. Comments? Preferences? Better ideas? Is it ready for a Pace? From owner-atom-syntax@mail.imc.org Fri Feb 4 18:44:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21323 for ; Fri, 4 Feb 2005 18:44:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Na2k3007574; Fri, 4 Feb 2005 15:36:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Na2k1007573; Fri, 4 Feb 2005 15:36:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Na1ql007563 for ; Fri, 4 Feb 2005 15:36:01 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so631548rne for ; Fri, 04 Feb 2005 15:35:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=i9pVHO35VB50bz0KRrbXNoNCV/oDgtQ4Zhi818fV86jNarD2bEvWc8Ykoj6C348mEudNQ/5ZN2EsWIVsHR+ZYbmxUGnc4T0XMrYYW1XuUp57j7ljD8s497b9hfJWiOEmqmhrA/UTT4OXK2HXGv6Oq7cYs80NOkocYDc5TutiLhQ= Received: by 10.38.151.15 with SMTP id y15mr216121rnd; Fri, 04 Feb 2005 15:35:56 -0800 (PST) Received: by 10.38.72.64 with HTTP; Fri, 4 Feb 2005 15:35:56 -0800 (PST) Message-ID: <2bcdc7c405020415351b04d69d@mail.gmail.com> Date: Fri, 4 Feb 2005 15:35:56 -0800 From: James Snell Reply-To: James Snell To: Mark Nottingham Subject: Re: PaceProfile - new Cc: Atom Syntax In-Reply-To: <1656f5607c432655a5cf1b2ea08703bf@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> <420401A2.70701@gmail.com> <1656f5607c432655a5cf1b2ea08703bf@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Absolutely, there would be a core default profile defined in the Atom syntax spec. @profiles="core syndication" @profiles="core blog", etc. On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham wrote: > > On Feb 4, 2005, at 3:13 PM, James M Snell wrote: > > > If a profile is indicated that the UA does not understand, the UA > > could safely ignore the profile and just work off the minimally > > required core metadata elements. > > Ah, that's the rub; I'm trying to say that that set of 'core' elements > is, in and of itself, a profile. > > > -- > Mark Nottingham http://www.mnot.net/ > > -- - James Snell http://www.snellspace.com jasnell@gmail.com From owner-atom-syntax@mail.imc.org Fri Feb 4 18:54:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22181 for ; Fri, 4 Feb 2005 18:54:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NlRUq008174; Fri, 4 Feb 2005 15:47:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14NlRP7008173; Fri, 4 Feb 2005 15:47:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.143.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NlQnT008165 for ; Fri, 4 Feb 2005 15:47:26 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 992DE17C for ; Fri, 4 Feb 2005 15:47:21 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j14NlJLf019210 for ; Fri, 4 Feb 2005 15:47:21 -0800 (PST) Date: Fri, 04 Feb 2005 15:47:21 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: Entry order Message-ID: <52E0F3C6E54E8815A477B729@adsl-64-166-133-243.dsl.snfc21.pacbell.net> In-Reply-To: <540e373205020414287097903f@mail.gmail.com> References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <540e373205020414287097903f@mail.gmail.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 4, 2005 4:28:53 PM -0600 "Roger B." wrote: >> If clients are told to ignore the order, and given only an updated timestamp, >> there is no way to show "most recent headlines"... > > At a single moment within a feedstream, sure... but the next time an > entry is added to that feed, I'll have no problem letting the user > know that this is new stuff. But if three are added, you can't order those three. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Fri Feb 4 19:10:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23178 for ; Fri, 4 Feb 2005 19:10:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1504JxJ009276; Fri, 4 Feb 2005 16:04:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1504JQU009275; Fri, 4 Feb 2005 16:04:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.206]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1504GO9009259 for ; Fri, 4 Feb 2005 16:04:19 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1048211wri for ; Fri, 04 Feb 2005 16:04:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oybg5IYzwJZZvUF806TdguFBBAEOIcs55KXYioKwS/Fb/44FQXjxqBIBK/jyAiVcMx/4zZJfEAqICTMvAlIhKNumHhCA0pNghbrWa5OrXJauKVUXcvJfO4p0i/SIDCDs3VLi2B2mTHo4nK4rlNSU3JwWSBqRcF1wSuZL5FOAQ94= Received: by 10.54.5.12 with SMTP id 12mr201767wre; Fri, 04 Feb 2005 16:04:11 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 45sm229216wri.2005.02.04.16.04.11; Fri, 04 Feb 2005 16:04:11 -0800 (PST) Message-ID: <42040D77.7010403@gmail.com> Date: Fri, 04 Feb 2005 16:04:07 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Nottingham , atom-syntax@imc.org Subject: Re: PaceProfile - new References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> <420401A2.70701@gmail.com> <1656f5607c432655a5cf1b2ea08703bf@mnot.net> <2bcdc7c405020415351b04d69d@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit True, but I don't think it needs to be anything all that complicated. A profile defines what metadata elements [must|must not|may|may not|should|should not] be found in that particular entry/feed. What more beyond that would be required? - James M Snell Mark Nottingham wrote: > but then you get into a composition model for the requirements of > profiles... > > > On Feb 4, 2005, at 3:35 PM, James Snell wrote: > >> Absolutely, there would be a core default profile defined in the Atom >> syntax spec. @profiles="core syndication" @profiles="core blog", etc. >> >> >> On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham wrote: >> >>> >>> On Feb 4, 2005, at 3:13 PM, James M Snell wrote: >>> >>>> If a profile is indicated that the UA does not understand, the UA >>>> could safely ignore the profile and just work off the minimally >>>> required core metadata elements. >>> >>> >>> Ah, that's the rub; I'm trying to say that that set of 'core' elements >>> is, in and of itself, a profile. >>> >>> >>> -- >>> Mark Nottingham http://www.mnot.net/ >>> >>> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> jasnell@gmail.com >> >> > > -- > Mark Nottingham http://www.mnot.net/ > > From owner-atom-syntax@mail.imc.org Fri Feb 4 19:11:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23262 for ; Fri, 4 Feb 2005 19:11:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1506PxH009844; Fri, 4 Feb 2005 16:06:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1506OeD009841; Fri, 4 Feb 2005 16:06:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ussjmh01.bea.com (ussjmh01.bea.com [63.96.162.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1506NW0009829 for ; Fri, 4 Feb 2005 16:06:23 -0800 (PST) (envelope-from markn@bea.com) Received: from ussjfe02.amer.bea.com (ussjfe02b.bea.com [172.16.120.56]) by ussjmh01.bea.com (Switch-3.0.5/Switch-3.0.0) with ESMTP id j1506F27012523; Fri, 4 Feb 2005 16:06:15 -0800 Received: from USSFEX01.amer.bea.com ([10.32.0.56]) by ussjfe02.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Feb 2005 16:06:15 -0800 Received: from [172.16.1.2] ([192.168.114.209]) by USSFEX01.amer.bea.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 4 Feb 2005 16:06:15 -0800 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <01cce2ce94ff53a3fb15bf36cb16e88e@bea.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 16:06:09 -0800 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) X-OriginalArrivalTime: 05 Feb 2005 00:06:15.0458 (UTC) FILETIME=[82621820:01C50B16] X-PMX-Version: 4.7.0.111621, Antispam-Engine: 2.0.2.0, Antispam-Data: 2005.2.4.7 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Just a note; I'm planning to remove the Identity Construct from -06, because it's only used in one place (the definition of atom:id). Otherwise, this sounds like a reasonable start. On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote: > > On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote: >> "An Identity construct is an element whose content conveys an >> unchanging identifier which MUST be universally unique within Atom >> Documents to the set of all versions and instantiations of the >> resource that the construct's parent instantiates." > > Okay, getting serious now, there is room for clarification. How about > we replace this: > >> "3.5 Identity Constructs >> An Identity construct is an element whose content conveys a >> permanent, universally unique identifier for the construct's parent." > > with this: > > 3.5 Identity Constructs > > An Identity construct is an element whose content conveys a permanent, > universally unique identifier for the resource > (instantiated|described) by the construct's parent element. An Atom > Document MAY contain multiple (revisions|versions) of the same > resource, in which case the content of the Identity construct for each > would be identical. Applications MAY decline to display more than one > version of each resource. > > Comments? Preferences? Better ideas? Is it ready for a Pace? > > > -- Mark Nottingham Principal Technologist Office of the CTO BEA Systems From owner-atom-syntax@mail.imc.org Fri Feb 4 19:15:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23495 for ; Fri, 4 Feb 2005 19:15:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1509Nfp010110; Fri, 4 Feb 2005 16:09:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1509NEg010109; Fri, 4 Feb 2005 16:09:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1509MdI010103 for ; Fri, 4 Feb 2005 16:09:22 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (unknown [63.96.165.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id F2EC551A34; Fri, 4 Feb 2005 19:09:20 -0500 (EST) In-Reply-To: <42040D77.7010403@gmail.com> References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> <420401A2.70701@gmail.com> <1656f5607c432655a5cf1b2ea08703bf@mnot.net> <2bcdc7c405020415351b04d69d@mail.gmail.com> <42040D77.7010403@gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1b8e25bab10b0aae7923051ccac092ff@mnot.net> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: PaceProfile - new Date: Fri, 4 Feb 2005 16:09:18 -0800 To: jasnell@gmail.com X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was thinking of profiles only specifying: - what metadata is required to be present - optionally for each one that's required, the maximum number that can be present If profiles are constrained as such, they're pretty trivial to compose; if we allow them to say what *isn't* allowed to be there, it gets much more complex. It also goes against the spirit of extensibility... On Feb 4, 2005, at 4:04 PM, James M Snell wrote: > True, but I don't think it needs to be anything all that complicated. > A profile defines what metadata elements [must|must not|may|may > not|should|should not] be found in that particular entry/feed. What > more beyond that would be required? > > - James M Snell > > Mark Nottingham wrote: >> but then you get into a composition model for the requirements of >> profiles... >> On Feb 4, 2005, at 3:35 PM, James Snell wrote: >>> Absolutely, there would be a core default profile defined in the Atom >>> syntax spec. @profiles="core syndication" @profiles="core blog", >>> etc. >>> >>> >>> On Fri, 4 Feb 2005 15:19:59 -0800, Mark Nottingham >>> wrote: >>> >>>> >>>> On Feb 4, 2005, at 3:13 PM, James M Snell wrote: >>>> >>>>> If a profile is indicated that the UA does not understand, the UA >>>>> could safely ignore the profile and just work off the minimally >>>>> required core metadata elements. >>>> >>>> >>>> Ah, that's the rub; I'm trying to say that that set of 'core' >>>> elements >>>> is, in and of itself, a profile. >>>> >>>> >>>> -- >>>> Mark Nottingham http://www.mnot.net/ >>>> >>>> >>> >>> >>> -- >>> - James Snell >>> http://www.snellspace.com >>> jasnell@gmail.com >>> >>> >> -- >> Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Fri Feb 4 19:16:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23562 for ; Fri, 4 Feb 2005 19:16:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150Ahd7010225; Fri, 4 Feb 2005 16:10:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j150AhJp010224; Fri, 4 Feb 2005 16:10:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150AfEd010211; Fri, 4 Feb 2005 16:10:42 -0800 (PST) (envelope-from tbray@textuality.com) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j150AfVu019912; Fri, 4 Feb 2005 17:10:41 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00LRCWHSO1@edgemail1.Central.Sun.COM>; Fri, 04 Feb 2005 17:10:41 -0700 (MST) Received: from [192.168.1.13] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005GHWHSUN@mail.sun.net>; Fri, 04 Feb 2005 17:10:40 -0700 (MST) Date: Fri, 04 Feb 2005 16:10:51 -0800 From: Tim Bray Subject: Re: Call for final Paces for consideration: deadline imminent In-reply-to: <200502042247.CNL09336@ms8.netsolmail.com> To: bob@wyman.us Cc: "'Mark Nottingham'" , "'Paul Hoffman'" , "'Atom WG'" Message-id: <722004e55be425da847f82e93c6ee2a4@textuality.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <200502042247.CNL09336@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote: > Paul Hoffman wrote: >> That means that you're not allowed to [use] the same atom:id in any >> two entries, ever. > We have atom:modified in order to indicate that an instance is a > modified version of a previously published entry. We do? I don't think so. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 19:30:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24360 for ; Fri, 4 Feb 2005 19:30:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150N6GX011595; Fri, 4 Feb 2005 16:23:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j150N6IF011594; Fri, 4 Feb 2005 16:23:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.sofari.com ([12.43.53.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150N6CE011588 for ; Fri, 4 Feb 2005 16:23:06 -0800 (PST) (envelope-from burton@newsmonster.org) Received: from [192.168.1.108] ([12.43.53.196]) by mail.sofari.com (8.12.11/8.12.3/Debian-6.6) with ESMTP id j150N4Q9010661; Fri, 4 Feb 2005 16:23:04 -0800 Message-ID: <420411E4.6060200@newsmonster.org> Date: Fri, 04 Feb 2005 16:23:00 -0800 From: "Kevin A. Burton" User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 X-Accept-Language: en-us, en MIME-Version: 1.0 To: java-syndication@yahoogroups.com, rss-dev@yahoogroups.com, Atom Syntax Subject: Open Comments..... Content-Type: multipart/alternative; boundary="------------090200050109020103000501" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------090200050109020103000501 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Any feedback on this guys? Curious to see what type of interest there is here... http://wiki.apache.org/jakarta-commons/FeedParser_2fOpenComments -- Use Rojo (RSS/Atom aggregator). Visit http://rojo.com. Ask me for an invite! Also see irc.freenode.net #rojo if you want to chat. Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html If you're interested in RSS, Weblogs, Social Networking, etc... then you should work for Rojo! If you recommend someone and we hire them you'll get a free iPod! Kevin A. Burton, Location - San Francisco, CA AIM/YIM - sfburtonator, Web - http://peerfear.org/ GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412 --------------090200050109020103000501 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Any feedback on this guys?  Curious to see what type of interest there is here...

http://wiki.apache.org/jakarta-commons/FeedParser_2fOpenComments

-- 

Use Rojo (RSS/Atom aggregator).  Visit http://rojo.com. Ask me for an 
invite!  Also see irc.freenode.net #rojo if you want to chat.

Rojo is Hiring! - http://www.rojonetworks.com/JobsAtRojo.html

If you're interested in RSS, Weblogs, Social Networking, etc... then you 
should work for Rojo!  If you recommend someone and we hire them you'll 
get a free iPod!
    
Kevin A. Burton, Location - San Francisco, CA
       AIM/YIM - sfburtonator,  Web - http://peerfear.org/
GPG fingerprint: 5FB2 F3E2 760E 70A8 6174 D393 E84D 8D04 99F1 4412
--------------090200050109020103000501-- From owner-atom-syntax@mail.imc.org Fri Feb 4 19:31:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24418 for ; Fri, 4 Feb 2005 19:31:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150OHpU011679; Fri, 4 Feb 2005 16:24:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j150OHrb011678; Fri, 4 Feb 2005 16:24:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150OGu0011671 for ; Fri, 4 Feb 2005 16:24:17 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j150OGdt014733 for ; Fri, 4 Feb 2005 17:24:16 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBE00MMKX4BNN@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Fri, 04 Feb 2005 17:24:11 -0700 (MST) Received: from [192.168.1.13] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBE005NYX4AUK@mail.sun.net> for atom-syntax@imc.org; Fri, 04 Feb 2005 17:24:11 -0700 (MST) Date: Fri, 04 Feb 2005 16:24:21 -0800 From: Tim Bray Subject: Re: Call for final Paces for consideration: deadline imminent In-reply-to: To: Antone Roundy Cc: atom-syntax@imc.org Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 4, 2005, at 3:23 PM, Antone Roundy wrote: > > On Friday, February 4, 2005, at 03:12 PM, Antone Roundy wrote: >> "An Identity construct is an element whose content conveys an >> unchanging identifier which MUST be universally unique within Atom >> Documents to the set of all versions and instantiations of the >> resource that the construct's parent instantiates." > > Okay, getting serious now, there is room for clarification. How about > we replace this: You guys are making good progress, I'm impressed. Now please don't forget to Pace-ify whatever you end up with for Monday. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 19:33:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21327 for ; Fri, 4 Feb 2005 18:44:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NYMIY007504; Fri, 4 Feb 2005 15:34:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14NYMDG007503; Fri, 4 Feb 2005 15:34:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14NYMc6007497 for ; Fri, 4 Feb 2005 15:34:22 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxCxu-00022e-Rz; Fri, 04 Feb 2005 23:34:18 +0000 Message-ID: <4204067B.8060504@franklinmint.fm> Date: Fri, 04 Feb 2005 18:34:19 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: Call for final Paces for consideration: deadline imminent References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > 3.5 Identity Constructs > > An Identity construct is an element whose content conveys a permanent, > universally unique identifier for the resource (instantiated|described) > by the construct's parent element. An Atom Document MAY contain > multiple (revisions|versions) of the same resource, in which case the > content of the Identity construct for each would be identical. > Applications MAY decline to display more than one version of each resource. > > Comments? Preferences? Better ideas? Is it ready for a Pace? > It doesn't make a bit of sense unless you define "entry" and "feed", as has been pointed out numerous times over the past few days. This text is defining a feed in the text on atom:id, which should be short. If you define feed as a "sliding window on a stream of entries", your definition makes sense. If you define feed as a "server-determined representation of the current status of a set of entries", then it only makes sense to include one entry per atom:id. I would argue the second definition makes a lot more sense and accurately reflects real-world usage, where even the RDF formats recommend against repeating rdf:about. Robert Sayre From owner-atom-syntax@mail.imc.org Fri Feb 4 19:49:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25887 for ; Fri, 4 Feb 2005 19:49:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150gPXB012646; Fri, 4 Feb 2005 16:42:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j150gP86012645; Fri, 4 Feb 2005 16:42:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j150gO26012639 for ; Fri, 4 Feb 2005 16:42:24 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j150gJmm007596; Fri, 4 Feb 2005 19:42:23 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNL44544 (AUTH bob@wyman.us); Fri, 4 Feb 2005 19:42:18 -0500 (EST) Message-Id: <200502050042.CNL44544@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Tim Bray'" Cc: "'Atom WG'" Subject: RE: Call for final Paces for consideration: deadline imminent Date: Fri, 4 Feb 2005 19:38:34 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <722004e55be425da847f82e93c6ee2a4@textuality.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcULFykA3e/xXAZNRFy32o4GP1ZJCAAA7dhg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Clearly, I meant atom:updated not atom:modified... My apologies for the slip. bob wyman -----Original Message----- From: Tim.Bray@Sun.COM [mailto:Tim.Bray@Sun.COM] On Behalf Of Tim Bray Sent: Friday, February 04, 2005 7:11 PM To: bob@wyman.us Cc: 'Mark Nottingham'; 'Paul Hoffman'; 'Atom WG' Subject: Re: Call for final Paces for consideration: deadline imminent On Feb 4, 2005, at 2:43 PM, Bob Wyman wrote: > Paul Hoffman wrote: >> That means that you're not allowed to [use] the same atom:id in any >> two entries, ever. > We have atom:modified in order to indicate that an instance is a > modified version of a previously published entry. We do? I don't think so. -Tim From owner-atom-syntax@mail.imc.org Fri Feb 4 20:17:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27691 for ; Fri, 4 Feb 2005 20:17:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151A9TT014724; Fri, 4 Feb 2005 17:10:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j151A9X7014723; Fri, 4 Feb 2005 17:10:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151A8aT014704 for ; Fri, 4 Feb 2005 17:10:08 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j1519ZFu008556; Sat, 5 Feb 2005 01:09:36 GMT In-Reply-To: <1b8e25bab10b0aae7923051ccac092ff@mnot.net> References: <2bcdc7c405020322203ca7fc57@mail.gmail.com> <4203460F.7010901@dehora.net> <42039FAB.3080603@dehora.net> <420401A2.70701@gmail.com> <1656f5607c432655a5cf1b2ea08703bf@mnot.net> <2bcdc7c405020415351b04d69d@mail.gmail.com> <42040D77.7010403@gmail.com> <1b8e25bab10b0aae7923051ccac092ff@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-10-409558257; protocol="application/pkcs7-signature" Message-Id: <19d150da00ca9fc96ed4e3a678fbbfdc@mac.com> Cc: jasnell@gmail.com, atom-syntax@imc.org From: Graham Subject: Re: PaceProfile - new Date: Sat, 5 Feb 2005 01:09:36 +0000 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-10-409558257 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 12:09 am, Mark Nottingham wrote: > > I was thinking of profiles only specifying: > - what metadata is required to be present > - optionally for each one that's required, the maximum number that > can be present > > If profiles are constrained as such, they're pretty trivial to > compose; if we allow them to say what *isn't* allowed to be there, it > gets much more complex. It also goes against the spirit of > extensibility... I fail to see what constraints in the current version justify different profiles, especially given the inevitable breaks in interop. Can you give us some examples? Graham --Apple-Mail-10-409558257 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MDEwOTM3WjAjBgkqhkiG9w0BCQQxFgQUL8MICC27Jn4SGRR8X30d8ujp uJIweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAPnmHuD7I51BVO4FqSwNncbaX KTSzKbYx2iB9EeT/paBGd6IBbni0tpmAW8J3c0MghXcLAAoIQKCnwkYdyzUmJRc8OaVxTIfAz9Np KDOfTBfU+zHBP2swYFEH2EtFAnHv/WS+HmHGS+b804O5XsLc0j6AuobttS/eEINWSOowTWThzFGv ds9LrnkHgDGxAmZBbEfJDY1G85Ksu2N8N7DxnYA469IUhbVcF7JJo1bGaCnHUKMY8I+HH+wsljNZ oFEcmb8ZhzyVfTXtMZh4xeKcbxGnjebHcomONQzRnhHz0EytNi3jofIRrOBZQL9Egz6Z3z1W67sm jYYjtDtQqkbqEAAAAAAAAA== --Apple-Mail-10-409558257-- From owner-atom-syntax@mail.imc.org Fri Feb 4 20:22:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27891 for ; Fri, 4 Feb 2005 20:22:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151F7Ro015417; Fri, 4 Feb 2005 17:15:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j151F7Xv015416; Fri, 4 Feb 2005 17:15:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151F6S8015404 for ; Fri, 4 Feb 2005 17:15:07 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j151E7Gr009282; Sat, 5 Feb 2005 01:14:11 GMT In-Reply-To: <1311114903.20050203001838@djpowell.net> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-11-409829928; protocol="application/pkcs7-signature" Message-Id: Cc: Atom Syntax From: Graham Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 01:14:08 +0000 To: David Powell X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-11-409829928 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 3 Feb 2005, at 12:18 am, David Powell wrote: > {{{ This specification assigns no significance to the order of > atom:entry elements within the feed. Processors MAY present entries in > a different order to which they are appear in an Atom Feed Document. > }}} First sentence no, but the second sentence says all that we need to say and no more. Graham --Apple-Mail-11-409829928 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MDExNDA5WjAjBgkqhkiG9w0BCQQxFgQU1HxqiTEHQ7SrqvfNSHsFNzmA dmgweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAdbRRLfmnF69UT3Dh6e8BGdrI MqL6x0CdioQwPab8o+k10K6tgCIoL7nf3RdoAMIIMFANOqW+i2TDUdz+2jD5PlCqSvcUmb6I4kdf iNPNGsx6JsYYsGBVxpAaGPdkiYCjTCE4Pn/26RQW+kh3xO0OpXiB8uJkOjHfLsrlwHdL8DTZElHE oTutPhTfWEZTRg3KR789EOVbT5dJXtPu9H0auqWMF1J1Juj3mpl+97xDh8P/qoyhF56meXTIMfVl IvDgNbHhmxQnwvbtsblshptuZilYohjmsIGF1N23+VlqWGg45intVUeYkFf8aMr6Ge4js3F7NpJ4 3/KiytjnGAeAlQAAAAAAAA== --Apple-Mail-11-409829928-- From owner-atom-syntax@mail.imc.org Fri Feb 4 20:23:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27951 for ; Fri, 4 Feb 2005 20:23:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151H7US015616; Fri, 4 Feb 2005 17:17:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j151H7OR015615; Fri, 4 Feb 2005 17:17:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151H6Zx015599 for ; Fri, 4 Feb 2005 17:17:07 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j151GGcQ009573; Sat, 5 Feb 2005 01:16:16 GMT In-Reply-To: <54e8033a44284de773d148639e13e44c@mac.com> References: <878y658hqj.fsf@nwalsh.com> <54e8033a44284de773d148639e13e44c@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-12-409959152; protocol="application/pkcs7-signature" Message-Id: <3b1e870f3b27d4ddb55dd4db6e0e034a@mac.com> Cc: Atom Syntax From: Graham Subject: Re: PaceRemoveVersionAttr Date: Sat, 5 Feb 2005 01:16:17 +0000 To: Norman Walsh X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-12-409959152 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 3 Feb 2005, at 9:36 pm, Graham wrote: > On 3 Feb 2005, at 9:18 pm, Norman Walsh wrote: > >> I think, on balance, I'm +1 for keeping it, but I doubt I'd lie down >> in the road over it. > > Yes. I like it too. Just to clarify, I like it being there for informational/statistics/debugging purposes. I don't see what harm it causes or why there's any need to remove it. Graham --Apple-Mail-12-409959152 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MDExNjE4WjAjBgkqhkiG9w0BCQQxFgQUruPp1TUG0+cQr5xD282ZDqkz ZlcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEALJ1PW90t4pd7QGVNMHq3Ef4r RvAthfAT8SxpWOXqkfa8H1rmxgeBpRw/VmCeA7xrhVsytnFDL1GJJe2wq9R37gYmHeKbedEENQz0 NzHjAL7JZFeTIFK+kr4lPz4FerfX9WeDZ2xwLH4WwsMyLcbgD5oaShSqKKn/zm7ud/V0USCiSXH+ TSzTEZfp/OY+7BOjeAYgdmNr3Qrif6CF3JOfLAaBfY696myVixpxS0OivrGc2twhBlmAeWXtpq3+ YfhUO6iL4msghb2AtIqy0fQ8H0bD6pN9DDK7NLY/XGuY9FtkYae4G2h7c1iyFMtK0JAv7Ea1tYdI lyc/q/LUSgBM3wAAAAAAAA== --Apple-Mail-12-409959152-- From owner-atom-syntax@mail.imc.org Fri Feb 4 20:26:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28100 for ; Fri, 4 Feb 2005 20:26:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151LIl7015898; Fri, 4 Feb 2005 17:21:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j151LIit015897; Fri, 4 Feb 2005 17:21:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151LHEj015884 for ; Fri, 4 Feb 2005 17:21:17 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j151KDAq010232; Sat, 5 Feb 2005 01:20:17 GMT In-Reply-To: <200502041944.CNK42464@ms8.netsolmail.com> References: <200502041944.CNK42464@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-13-410196191; protocol="application/pkcs7-signature" Message-Id: <76e2781b7b793df8c9eee85a622023a2@mac.com> Cc: "'Roy T. Fielding'" , "'Tim Bray'" , mint@franklinmint.fm, "'Atom Syntax'" From: Graham Subject: Re: PaceHeadless Date: Sat, 5 Feb 2005 01:20:14 +0000 To: bob@wyman.us X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-13-410196191 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit -1 Putting everything in one group and requiring it to be first is useful, and also adds consistency to head-in-entry, as evidenced by the introduction of the feeder element. Also "feeder" is a horrible word. Graham --Apple-Mail-13-410196191 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MDEyMDE1WjAjBgkqhkiG9w0BCQQxFgQU+BqBaZGDfZyjdSrYxhl3z+ud fXoweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEARJoFEmhOCuJxniuryHg2cj+R DwmaXFV2z+5CAOr5Rp1AP8jdX2K7Q81yX26AONrPnz7rer2ActHOnJmNcHjYzTFKg6mbeuQvq4AD +Nb0AUcoGFnaNQkQ7M878H7aUSdvm9jLBAIrzSoNRCpQvYcZbd2gUv2vP40v52PMNOt1eJbxr7ar MM5JHBONchjXc8Fd+qB+JytCH7rIaU83SRcJlnjDQX0sdzpjtn3d2pSifCdQ/r8V2twDByFXoV4g 4HxXL77uSiojj2WSDVKDyHbCCU+7MvjkOc+dxjKp5nu14EjSh0mLYkA993EG/pDt9jBVC15E1GbK tKCu0oHZEJG/sQAAAAAAAA== --Apple-Mail-13-410196191-- From owner-atom-syntax@mail.imc.org Fri Feb 4 20:49:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29438 for ; Fri, 4 Feb 2005 20:49:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151arQA016735; Fri, 4 Feb 2005 17:36:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j151arws016734; Fri, 4 Feb 2005 17:36:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j151aqFv016728 for ; Fri, 4 Feb 2005 17:36:52 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxErn-00038R-4g; Sat, 05 Feb 2005 01:36:07 +0000 Message-ID: <42042305.4060204@franklinmint.fm> Date: Fri, 04 Feb 2005 20:36:05 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: bob@wyman.us, "'Roy T. Fielding'" , "'Tim Bray'" , "'Atom Syntax'" Subject: Re: PaceHeadless References: <200502041944.CNK42464@ms8.netsolmail.com> <76e2781b7b793df8c9eee85a622023a2@mac.com> In-Reply-To: <76e2781b7b793df8c9eee85a622023a2@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > -1 > > Putting everything in one group and requiring it to be first is useful, > and also adds consistency to head-in-entry, as evidenced by the > introduction of the feeder element. Also "feeder" is a horrible word. And "head" doesn't suck? I struggle to type a sentence on the subject without making an unintentional pun. "source-feed" is fine. The section on atom:head is totally confusing and bad--it's easier if you just do it the way PubSub does it *right now*. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 02:48:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09256 for ; Sat, 5 Feb 2005 02:48:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157PEL9073896; Fri, 4 Feb 2005 23:25:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j157PEqV073895; Fri, 4 Feb 2005 23:25:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157OoOs073673 for ; Fri, 4 Feb 2005 23:24:55 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j148URrD010349; Fri, 4 Feb 2005 03:31:21 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNH96776; Fri, 4 Feb 2005 03:29:30 -0500 (EST) Message-Id: <200502040829.CNH96776@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Robert Sayre'" , "'Antone Roundy'" Cc: Subject: Don't mess with HeadInEntry! Date: Fri, 4 Feb 2005 03:29:30 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUKjtCFbTYLvj40SUqg94xIiMaNLQAAUOhQ In-Reply-To: <420320C6.8030504@franklinmint.fm> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > HeadInEntry is trivial to do as an extension, so there's no > reason to leave it in. There are a number of excellent reasons to leave it in! 1. Just about the only functional "advantage" that Atom has over RSS is that HeadInEntry provides core support for aggregated feeds. If you're unwilling to innovate in even this one tiny spot, why the heck bother with this effort at all? Perhaps we should all join Dare over in RSS-land... With Microsoft being so anti-Atom, we need *some* argument for expending the effort and political capital needed to support this format! 2. The Internet Draft "Atom over XMPP" requires HeadInEntry in order to provide attribution for entries. 3. Entry Documents will often need HeadInEntry to identify their origin. 4. We've been talking about HeadInEntry ever since I proposed it back in June at the Atom Community meeting. On numerous occasions, the group as a whole has rejected the various "feed of feed" proposals as overly complex and unnecessary. It is a bit bizarre to see all this being rehashed in a rush as we drive towards a Last Call. 5. If HeadInEntry is not in the core, it will not be widely implemented by clients. Given the speed with which the IETF approves RFC's it is also likely that it would be a *long* time before an extension RFC could get approved -- yet we need HeadInEntry TODAY! The reduced penetration of HeadInEntry that would come from it being defined in a future extension makes it largely useless and not worth the effort to even try to get a formal extension. What you'll be doing is forcing people who are in the aggregation business to define private extensions to address these issues and to do so outside the Atom process. We have work to do and customers to serve. We can't just put our businesses on hold for years... 6. All of the alternatives that have been proposed require drastic and unlikely modifications to the design and architecture of readers. (i.e. stuff like adding an aggregation document!!) Such proposals are not viable alternatives no matter how sweet one might find their abstractions... 7. We at PubSub have had "running code" since July that demonstrates the utility of HeadInEntry (i.e. our "ps:source-feed"). None of the other proposals that have been made are supported or "proven" by running-code. There is no field experience in their use. I have also not seen any alternatives proposed by anyone who actually appears to be in the feed aggregation business... We decided to support HeadInEntry. It doesn't make sense to back off now. Deferring HeadInEntry to a non-core extension essentially kills it and ensures that Atom use will provide virtually no advantage to anyone who is building aggregated feeds. bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 02:49:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09342 for ; Sat, 5 Feb 2005 02:49:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157fXdi079950; Fri, 4 Feb 2005 23:41:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j157fXux079949; Fri, 4 Feb 2005 23:41:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157fWRG079890 for ; Fri, 4 Feb 2005 23:41:32 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1104625wri for ; Fri, 04 Feb 2005 23:41:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=o7W4dVQYo48OhHFHwjcFBFHctUwr42BDkfZ1shOTrlaEtoFL2foa67X1FmfDYYirhUYtPpWspiuyfAKymq8j01xwyWx0rMSHvpKQ/15LEpYQA2YUMJr3LjueqkdKOOy3k80DtFywjUeWh2kp204Ffsd3vZj4lcyasKwaarmwO7E= Received: by 10.54.5.72 with SMTP id 72mr167918wre; Fri, 04 Feb 2005 23:41:24 -0800 (PST) Received: by 10.54.18.2 with HTTP; Fri, 4 Feb 2005 23:41:24 -0800 (PST) Message-ID: <540e373205020423414e7211e5@mail.gmail.com> Date: Sat, 5 Feb 2005 01:41:24 -0600 From: "Roger B." Reply-To: "Roger B." To: "Kevin A. Burton" Subject: Re: Open Comments..... Cc: Atom Syntax In-Reply-To: <420411E4.6060200@newsmonster.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <420411E4.6060200@newsmonster.org> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Any feedback on this guys? Curious to see what type of interest there is > here... Kevin: Why would anyone want to fiddle around with HTML classes to indicate comments when they can just publish/consume comment feeds? Or did I misinterpret the purpose of the effort? -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Sat Feb 5 03:03:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10125 for ; Sat, 5 Feb 2005 03:03:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157rm7m084901; Fri, 4 Feb 2005 23:53:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j157rmk1084900; Fri, 4 Feb 2005 23:53:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j157rlGW084863 for ; Fri, 4 Feb 2005 23:53:48 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1106042wri for ; Fri, 04 Feb 2005 23:53:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=W59bQBlQGv+DreMkjfFO4fQkLVYWB1aKYe91JVZFv3yLqCNEbSzoAif7vEaVsoGyeRJ1+H9pMDeAwBYO4mor3cUVuX3W2yMcQUz1/9wa96Zmw91BbVx86iku368UwUiEvQ5YyxxGFFsaMA/ta2niIiqKyDn7b+xAwTeBNKWdY28= Received: by 10.54.5.72 with SMTP id 72mr171657wre; Fri, 04 Feb 2005 23:53:42 -0800 (PST) Received: by 10.54.18.2 with HTTP; Fri, 4 Feb 2005 23:53:42 -0800 (PST) Message-ID: <540e3732050204235361a71213@mail.gmail.com> Date: Sat, 5 Feb 2005 01:53:42 -0600 From: "Roger B." Reply-To: "Roger B." To: Walter Underwood Subject: Re: Entry order Cc: Atom Syntax In-Reply-To: <52E0F3C6E54E8815A477B729@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> <540e373205020414287097903f@mail.gmail.com> <52E0F3C6E54E8815A477B729@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > But if three are added, you can't order those three. Walter: I dunno... seems to me, if the publisher hasn't included atom:published info, then it's probably safe to assume that the order of those entries isn't important. -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Sat Feb 5 03:30:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11813 for ; Sat, 5 Feb 2005 03:30:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j158LDgX095009; Sat, 5 Feb 2005 00:21:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j158LDal095007; Sat, 5 Feb 2005 00:21:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j158LBK5094832 for ; Sat, 5 Feb 2005 00:21:12 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sat, 5 Feb 2005 21:21:26 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sat, 05 Feb 2005 19:20:39 +1100 Subject: Re: Posted PaceEntryOrder (was Entry order) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5/2/05 12:14 PM, "Graham" wrote: >> {{{ This specification assigns no significance to the order of >> atom:entry elements within the feed. Processors MAY present entries in >> a different order to which they are appear in an Atom Feed Document. >> }}} > > First sentence no, but the second sentence says all that we need to say > and no more. +1 .. while the spec assigns no significance, a publisher might want to have more important stories at the front of the feed, albeit knowing full well that some users will sort things whichever way they want, and some applications will insist on applying a default sort of their choice. e. From owner-atom-syntax@mail.imc.org Sat Feb 5 04:06:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13791 for ; Sat, 5 Feb 2005 04:06:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j158tHf7007122; Sat, 5 Feb 2005 00:55:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j158tHA6007121; Sat, 5 Feb 2005 00:55:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j158tHxe007071 for ; Sat, 5 Feb 2005 00:55:17 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 50752 invoked by uid 17064); 5 Feb 2005 08:55:09 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.2.206]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 08:55:09 -0000 In-Reply-To: <4204067B.8060504@franklinmint.fm> References: <4204067B.8060504@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1acdf403b446f8676ef198d67d2ea6c9@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: Call for final Paces for consideration: deadline imminent Date: Sat, 5 Feb 2005 09:54:42 +0100 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 00:34, Robert Sayre wrote: > Antone Roundy wrote: >> 3.5 Identity Constructs >> An Identity construct is an element whose content conveys a >> permanent, universally unique identifier for the resource >> (instantiated|described) by the construct's parent element. An Atom >> Document MAY contain multiple (revisions|versions) of the same >> resource, in which case the content of the Identity construct for >> each would be identical. Applications MAY decline to display more >> than one version of each resource. >> Comments? Preferences? Better ideas? Is it ready for a Pace? > > It doesn't make a bit of sense unless you define "entry" and "feed", > as has been pointed out numerous times over the past few days. This > text is defining a feed in the text on atom:id, which should be short. > > If you define feed as a "sliding window on a stream of entries", your > definition makes sense. If you define feed as a "server-determined > representation of the current status of a set of entries", then it > only makes sense to include one entry per atom:id. I would argue the > second definition makes a lot more sense and accurately reflects > real-world usage, where even the RDF formats recommend against > repeating rdf:about. I would argue that you are completely wrong on this one. It is the first sliding window version that represents current usage a lot better. When people move their feed document to the archive, the easiest way to do this, is just to copy the live feed document over to a new timestamped file and change the next and previous links. Your suggestion would mean they would have to go through all the archived versions (the feed documents you get to by following the "next" links in sequence), and eliminate all duplicate entries. That is a lot more time consuming. I find it really good in fact that people should be able to keep a history of the changes they make to their entries. That is the honest thing to do. Those who want to cheat can also get what they want by deleting previous entries. But it will require more work. In any case the current system is I think very well defined. I am +1 on it remaining this way, and would be seriously distraught at seeing it go. I am in fact amazed that this should come up so late in the discussion here. No wonder this group can't get any further along. The basic model is not even agreed to by everyone. As for the whole text on Identity constructs it is again one of those useless pieces of text that the group is forced to write out because of its refusal to use the appropriate tools. If you had used RDF as a model for what you are trying to write then you would long ago have finished the document, and it would be a lot shorter and clearer too. Henry > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sat Feb 5 05:06:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17615 for ; Sat, 5 Feb 2005 05:06:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j159vVFD029418; Sat, 5 Feb 2005 01:57:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j159vVrU029417; Sat, 5 Feb 2005 01:57:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j159vUle029410 for ; Sat, 5 Feb 2005 01:57:30 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 28310 invoked by uid 17064); 5 Feb 2005 09:57:29 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.238.194]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 09:57:29 -0000 In-Reply-To: <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> References: <200502040425.CNH01907@ms8.netsolmail.com> <37A214418F4EE3D8CE98B369@adsl-64-166-133-243.dsl.snfc21.pacbell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <02d1cabdc5468c7c4a99aa2d9b1f4662@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Atom Syntax'" From: Henry Story Subject: Re: Entry order Date: Sat, 5 Feb 2005 10:57:22 +0100 To: Walter Underwood X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Having started agreeing with the initial post, and having read more of the thread I am now divided about what the best position is. In some sense the order is of the entries should not matter. All the important data to order the entries is in the entries themselves given by the modified date, the creation date, ... So if we map a whole feed into an rdf graph nothing is lost. We can use the data in the graph to sort our entries as we wish. On the other hand an application reading a feed would expect the latest entries to be at the head of the feed. This is very important at the protocol level, because without this guarantee, a client that would like to present the latest version of an entry would be forced to read the whole feed document and all feed documents linked to it, in order to be able to correctly assess that the entry it has really is the latest one. I think imposing a fixed ordering is not very helpful. Services may pop up that order entries in different ways depending on the interests of the receiver. But perhaps there should be a way to specify what the order of the entries is, or at least give a way to specify that the entries are ordered inverse chronlogically by the modified date when they are. This may be a protocol issue, or it may just be a matter of adding a special info to the feed to specify its ordering. Henry Story http://bblfish.net/ On 4 Feb 2005, at 20:27, Walter Underwood wrote: > --On February 3, 2005 11:21:50 PM -0500 Bob Wyman wrote: >> David Powell wrote: >>> It looks like this might have got lost accidently when the >>> atom:head element was introduced. Previously Atom 0.3 said [1]: >>>> Ordering of the element children of atom:feed element MUST NOT be >>>> considered significant. >> +1. >> The order of entries in an Atom feed should NOT be significant. This >> is, I think, a very, very important point to make. > > -1 > > Is this a joke? This is like saying that the order of the entries in my > mailbox is not significant. Note that ordering a mailbox by date is not > the same thing as its native order. > > Feed order is the only way we have to show the publication order of > items > in a feed. I just looked at all my subscriptions, and there is only one > where the order might not be relevant, a security test for RSS readers. > That is clearly not within Atom's charter, so it doesn't count. > > wunder > -- > Walter Underwood > Principal Architect, Verity > From owner-atom-syntax@mail.imc.org Sat Feb 5 05:28:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18841 for ; Sat, 5 Feb 2005 05:28:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15AKklD037050; Sat, 5 Feb 2005 02:20:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15AKkr0037049; Sat, 5 Feb 2005 02:20:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gps05-c10d6.vodafone.net (mailer.vodafone.net [212.183.156.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15AKj7u036940 for ; Sat, 5 Feb 2005 02:20:45 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from Inbox (127.0.0.1) by gps05-c10d6.vodafone.net (NPlex 6.0.021C4.14) id 419B3EC800066D22; Sat, 5 Feb 2005 10:20:20 +0000 Message-ID: <419B3EC800066D22@gps05-c10d6.vodafone.net> (added by postmaster@vodafone.net) From: "David Powell" To: Cc: Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 10:20:15 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1432.1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >(I.e., I could come up with the UseLexicalOrdering extension, and >require processors to understand it to use the feed, assuming our >extensibility model supports that, which I very much hope it will). Ok, well I am assuming that we won’t have MustUnderstand extensions, therefore all extensions must be just informative. >My preference would be something like > >This specification assigns no significance to the order of atom:entry >elements within an Atom Feed Document. Atom Processors MAY present >entries in any order, unless a specific ordering is required by an >extension. > Given a model of only informative metadata extensions this wouldn't be valid, unless the spec said that the order was significant, then it would be acceptable to communcate a preferred display order using extensions. The question is basically, if I have a database does it need to preserve the sequence number of the entry within a document? Display order is a different matter, but for the option of lexical order, then the answer would need to be yes, but I don't think it would be worth it. -- Dave From owner-atom-syntax@mail.imc.org Sat Feb 5 05:42:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19538 for ; Sat, 5 Feb 2005 05:42:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15AU1r8040131; Sat, 5 Feb 2005 02:30:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15AU1QX040130; Sat, 5 Feb 2005 02:30:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ATuKp040086 for ; Sat, 5 Feb 2005 02:29:57 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so357898rnz for ; Sat, 05 Feb 2005 02:29:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=mC1PByv4M7OmS4Pfm+Kf1Q7ReNyhLdh+nJyiFPS8H07Rmnk5fx7gmMKLfkvow+uQW9ij156RfPJGn+mnNF4lE6MbqcUVFgJItdU18TAEIlM9vET2leOxgQzEZnLJV2i9PGEheu6Ob6nWzaNJw8VHXDTj0E8oUcnQDLTi13mYCiQ= Received: by 10.38.8.49 with SMTP id 49mr384460rnh; Sat, 05 Feb 2005 02:29:54 -0800 (PST) Received: by 10.38.179.46 with HTTP; Sat, 5 Feb 2005 02:29:54 -0800 (PST) Message-ID: <1f2ed5cd05020502293ca3984b@mail.gmail.com> Date: Sat, 5 Feb 2005 11:29:54 +0100 From: Danny Ayers Reply-To: Danny Ayers To: "Roger B." Subject: Re: Open Comments..... Cc: "Kevin A. Burton" , Atom Syntax In-Reply-To: <540e373205020423414e7211e5@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <420411E4.6060200@newsmonster.org> <540e373205020423414e7211e5@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sat, 5 Feb 2005 01:41:24 -0600, Roger B. wrote: > > > Any feedback on this guys? Curious to see what type of interest there is > > here... > > Kevin: Why would anyone want to fiddle around with HTML classes to > indicate comments when they can just publish/consume comment feeds? Or > did I misinterpret the purpose of the effort? I had the same reaction, apologies if I'm misinterpreting too. The motto that spontaneously emerged on this list was "It's the Entries, stupid!" - comments and trackbacks are just entries too, only with different metadata. Is there something else here? Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Feb 5 07:49:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27504 for ; Sat, 5 Feb 2005 07:49:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Cce5x087569; Sat, 5 Feb 2005 04:38:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Ccee4087568; Sat, 5 Feb 2005 04:38:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15CcdCp087560 for ; Sat, 5 Feb 2005 04:38:39 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 11810 invoked by uid 17064); 5 Feb 2005 12:38:39 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.238.194]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 12:38:39 -0000 In-Reply-To: <419B3EC800066D22@gps05-c10d6.vodafone.net> (added by postmaster@vodafone.net) References: <419B3EC800066D22@gps05-c10d6.vodafone.net> (added by postmaster@vodafone.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8d634a7b02a53e4ec0a314fad2c0db6c@bblfish.net> Content-Transfer-Encoding: 7bit Cc: , From: Henry Story Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 13:38:34 +0100 To: "David Powell" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 11:20, David Powell wrote: >> This specification assigns no significance to the order of atom:entry >> elements within an Atom Feed Document. Atom Processors MAY present >> entries in any order, unless a specific ordering is required by an >> extension. > > Given a model of only informative metadata extensions this wouldn't be > valid, unless the spec said that the order was significant, then it > would be acceptable to communcate a preferred display order using > extensions. > > The question is basically, if I have a database does it need to > preserve the sequence number of the entry within a document? You put this in terms of databases and I put the question in terms of graphs (which if you have an rdf database to store your triples comes to the same thing). And my feeling is here that we should not have to keep the sequence numbers of the order of the entries in the document. Perhaps this is what Roy Fielding is getting at when he speaks of there being confusion on this list between the data model and the interaction model. It is important for clients when they ask for a sequence of entries to know what the order those entries are coming in. This can save them a lot of processing time. But it should not be part of the syntax to specify a preferred order of the entries. > Display order is a different matter, but for the option of lexical > order, then the answer would need to be yes, but I don't think it > would be worth it. Display order on the client will also completely depend on what the client is trying to do. If the client is just interested in archiving all the entries, then any new feed be it an old one or a new one will be of interest: it will just be added to the database. If the client is interested in displaying the changes in a gui, this again may be completely up to the user. Some users may want only to see entries that they have read that have changed, as this may show a change of position of interest to them. Henry Story > > -- > Dave From owner-atom-syntax@mail.imc.org Sat Feb 5 07:56:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27826 for ; Sat, 5 Feb 2005 07:56:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Co4Da091240; Sat, 5 Feb 2005 04:50:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Co4pk091239; Sat, 5 Feb 2005 04:50:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Co4cC091231 for ; Sat, 5 Feb 2005 04:50:04 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 18753 invoked by uid 17064); 5 Feb 2005 12:50:04 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.238.194]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 12:50:04 -0000 In-Reply-To: <200502040829.CNH96776@ms8.netsolmail.com> References: <200502040829.CNH96776@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <12fea0271ebe426c4b6241d2164ee00c@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Antone Roundy'" , , "'Robert Sayre'" From: Henry Story Subject: atom extensibility: Re: Don't mess with HeadInEntry! Date: Sat, 5 Feb 2005 13:49:58 +0100 To: X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't have that much of an opinion now on the head in entry and various other proposals. But I do find your comment that moving something off to an extension essentially kills it to be a very important remark. This is clearly to say that Atom has not yet dealt with the extension part of the charter. And even though many people seem to willing to create fill in language for that part of the spec to make it seem like this part has been addressed, your on the ground initial reaction is the correct one: there is no well defined extension mechanism. So perhaps what we could do in the next weeks is fill in the work I started in my proposal AtomAsRDF, that would allow Atom to be seen as an RDF/XML document, though one constrained by an Relax-NG syntax. This will require a week or two of serious group effort, but then extensions will fall out from the RDF side of things. In the mean time I am fully behind every movement to remove non core elements from Atom. Lets have a clean spec well defined spec. When enough people are left outside of the core, then I am sure talk of extensions will finally get to be serious. Henry Story On 4 Feb 2005, at 09:29, Bob Wyman wrote: > We decided to support HeadInEntry. It doesn't make sense to back off > now. Deferring HeadInEntry to a non-core extension essentially kills > it and > ensures that Atom use will provide virtually no advantage to anyone > who is > building aggregated feeds. From owner-atom-syntax@mail.imc.org Sat Feb 5 08:44:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01147 for ; Sat, 5 Feb 2005 08:44:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15DaYuw003598; Sat, 5 Feb 2005 05:36:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15DaYqV003597; Sat, 5 Feb 2005 05:36:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15DaXcg003590 for ; Sat, 5 Feb 2005 05:36:34 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 40so362331rnz for ; Sat, 05 Feb 2005 05:36:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=eM7qNxmjHnPFf9K67RpyJcj0lIpyQGpUGtkHDIaRwQVRj/9F3B6gUQv/JqO36GRcPQv+x8I/BlsiznYopS0iZdERZrpECyO4PiT+1sohKEA+CvyxQ1WIDWByQTxj4Ib7fs6bJoDnU1EoIANwl1pdDJIYn186uQpzleJLfVnP54Y= Received: by 10.38.179.79 with SMTP id b79mr184785rnf; Sat, 05 Feb 2005 05:36:33 -0800 (PST) Received: by 10.38.179.46 with HTTP; Sat, 5 Feb 2005 05:36:33 -0800 (PST) Message-ID: <1f2ed5cd05020505361047e69d@mail.gmail.com> Date: Sat, 5 Feb 2005 14:36:33 +0100 From: Danny Ayers Reply-To: Danny Ayers To: bob@wyman.us Subject: Re: Entry order Cc: David Powell , Atom Syntax In-Reply-To: <200502040425.CNH01907@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman wrote: > >> Ordering of the element children of atom:feed element MUST NOT be > >> considered significant. +1. I accept there are cases where it might be useful to associate significance to document order, such as 'Top 10' . But I can't think of any which couldn't be better fulfilled by being explicit within the entries/feed. The killer problem of using doc order is that the feed data *will* be aggregated and republished. Far better to declare the information in the data (like the date) and let the client (or intermediary) sort according to the user's requirements. In a case like Top 10 an extension would be appropriate, link rel=first/next/previous being one way, RSS 1.0-style feed level ... being another. Cheers, Danny. -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Sat Feb 5 09:20:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03476 for ; Sat, 5 Feb 2005 09:20:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ED9TP015321; Sat, 5 Feb 2005 06:13:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15ED9bv015320; Sat, 5 Feb 2005 06:13:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ED7or015311 for ; Sat, 5 Feb 2005 06:13:09 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 6109 invoked by uid 17064); 5 Feb 2005 14:13:07 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.238.194]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 14:13:07 -0000 In-Reply-To: <429494207.20050128212711@djpowell.net> References: <429494207.20050128212711@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: Proof-of-concept RDF mapping for Atom Date: Sat, 5 Feb 2005 15:13:02 +0100 To: David Powell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Have you had any more luck with this part of the mapping? Is this a problem with the current Atom syntax if not? Henry Story On 28 Jan 2005, at 22:27, David Powell wrote: > I think it > handles everything except for xml:lang - I'm not sure what's happening > with xml:lang at the moment - but it should be possible to add it in a > similar way to xml:base. From owner-atom-syntax@mail.imc.org Sat Feb 5 09:32:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04106 for ; Sat, 5 Feb 2005 09:32:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15EQU1Z016348; Sat, 5 Feb 2005 06:26:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15EQUF5016347; Sat, 5 Feb 2005 06:26:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15EQTVT016340 for ; Sat, 5 Feb 2005 06:26:29 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id c16so728062rne for ; Sat, 05 Feb 2005 06:26:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Dd+wpGn2tmT3M0fJtnu4OM/LK8DUSw97qHWZzSUiZv+LkBVNlDFWqMODwd3Bp3BOnNMANUhL3VWYJBDMlhPWRX3o4SZIB5BRSf4ddM+1qIECLlWElwvC/fK1B5ER0QMwp69idcodP4LWfbHrHqn2tv3k7+fS57Q/Bkz3yVZoYA0= Received: by 10.38.71.66 with SMTP id t66mr249463rna; Sat, 05 Feb 2005 06:26:29 -0800 (PST) Received: by 10.38.151.18 with HTTP; Sat, 5 Feb 2005 06:26:29 -0800 (PST) Message-ID: <3f1451f505020506265ce98c47@mail.gmail.com> Date: Sat, 5 Feb 2005 09:26:29 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Mark Nottingham Subject: Re: Posted PaceEntryOrder (was Entry order) Cc: David Powell , Atom Syntax In-Reply-To: <8d352b08be6964ebc999a535e9c13f76@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham wrote: > > My preference would be something like > > This specification assigns no significance to the order of atom:entry > elements within an Atom Feed Document. Atom Processors MAY present > entries in any order, unless a specific ordering is required by an > extension. > > (I.e., I could come up with the UseLexicalOrdering extension, and > require processors to understand it to use the feed, assuming our > extensibility model supports that, which I very much hope it will). -1 Atom is a Must Ignore format. I would prefer: """The order of atom:entry elements is typically in reverse chronological order, though feeds MAY be constructed with entries in any order, and this specification assigns no significance to the order of atom:entry elements within an Atom Feed Document.""" There is no reason to even mention how the CLIENT presents the order of the entries in this spec. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sat Feb 5 11:16:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12175 for ; Sat, 5 Feb 2005 11:16:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15G6XQP023174; Sat, 5 Feb 2005 08:06:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15G6XfC023173; Sat, 5 Feb 2005 08:06:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15G6Wmw023164 for ; Sat, 5 Feb 2005 08:06:33 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1155974wri for ; Sat, 05 Feb 2005 08:06:27 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EY/PFjxVTWsGLxG/InXKoOJ8USXyC7R/PdADj5izaOqBMBfkh6WwG43+vIclFwg+0uedK6GRlBtQ39gCnT/A1ITrA4kHSD82Ir3UKiSIac5ycWbn5BmmFN0fhh18qwAllbuIkFbz82Kt1EmL35dpntqA5CuzdxbS4cbZH12BZO0= Received: by 10.54.41.50 with SMTP id o50mr1554wro; Sat, 05 Feb 2005 08:06:27 -0800 (PST) Received: by 10.54.18.2 with HTTP; Sat, 5 Feb 2005 08:06:27 -0800 (PST) Message-ID: <540e3732050205080611ad4d7e@mail.gmail.com> Date: Sat, 5 Feb 2005 10:06:27 -0600 From: "Roger B." Reply-To: "Roger B." To: Henry Story Subject: Re: atom extensibility: Re: Don't mess with HeadInEntry! Cc: bob@wyman.us, atom-syntax@imc.org In-Reply-To: <12fea0271ebe426c4b6241d2164ee00c@bblfish.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <200502040829.CNH96776@ms8.netsolmail.com> <12fea0271ebe426c4b6241d2164ee00c@bblfish.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > And even though many people seem to willing to create fill in language > for that part of the spec to make it seem like this part has been > addressed, your on the ground initial reaction is the correct one: > there is no well defined extension mechanism. Henry: I suspect that Bob's reaction would have been the same, no matter how well-defined the extension mechanism. Anything outside the core will have spotty (at best) support in aggregators and publishing tools. -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Sat Feb 5 11:25:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12579 for ; Sat, 5 Feb 2005 11:25:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GIqVQ024167; Sat, 5 Feb 2005 08:18:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GIqxb024166; Sat, 5 Feb 2005 08:18:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GIpe4024151 for ; Sat, 5 Feb 2005 08:18:51 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020516183601200g68fle>; Sat, 5 Feb 2005 16:18:36 +0000 Date: Sat, 5 Feb 2005 09:18:34 -0700 Subject: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceRepeatIdInDocument Abstract Explicitly state that multiple versions of the resource identified by a particular atom:id may appear in the same document. Also, clarify somewhat what the atom:id must be unique to. Rationale 1. In order to show the revision history of a particular entry, multiple revisions of the entry must be able to appear in the same document. 2. Changing the atom:id of the entry with each revision would severly reduce the duplicate detection value of atom:id. Proposal Replace the first sentence of section 3.5 of draft-ietf-atompub-format-05.txt with the following (with the choice of alternate terms left to comments made during discussion and the discretion of the editors): An Identity construct is an element whose content conveys a permanent, universally unique identifier for the resource (instantiated|described) by the construct's parent element. An Atom Document MAY contain multiple (revisions|versions) of the same resource, in which case the content of the Identity construct for each would be identical. Applications MAY decline to display more than one version of each resource. From owner-atom-syntax@mail.imc.org Sat Feb 5 11:31:09 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12986 for ; Sat, 5 Feb 2005 11:31:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GPJss024570; Sat, 5 Feb 2005 08:25:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GPJPC024569; Sat, 5 Feb 2005 08:25:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GPJbu024561 for ; Sat, 5 Feb 2005 08:25:19 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 10312 invoked by uid 17064); 5 Feb 2005 16:25:14 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.238.194]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 16:25:14 -0000 In-Reply-To: <12fea0271ebe426c4b6241d2164ee00c@bblfish.net> References: <200502040829.CNH96776@ms8.netsolmail.com> <12fea0271ebe426c4b6241d2164ee00c@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Bob Wyman , Atom Syntax , "'Antone Roundy'" , "'Robert Sayre'" From: Henry Story Subject: Re: atom extensibility: Re: Don't mess with HeadInEntry! Date: Sat, 5 Feb 2005 17:25:08 +0100 To: Henry Story X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 13:49, Henry Story wrote: > So perhaps what we could do in the next weeks is fill in the work > I started in my proposal AtomAsRDF, that would allow Atom to be > seen as an RDF/XML document, though one constrained by an Relax-NG > syntax. > This will require a week or two of serious group effort, but then > extensions will fall out from the RDF side of things. I was just looking at the RSS1.1 [1] spec again and noticed that this is exactly what they have done. They have: - a Relax NG syntax to constrain the syntax - an OWL ontology to describe the model I think this is a very good example. I am not completely happy with their model, but this just seems so easy and so clean. Please have a look at it. Henry [1] http://inamidst.com/rss1.1/ From owner-atom-syntax@mail.imc.org Sat Feb 5 11:40:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13640 for ; Sat, 5 Feb 2005 11:40:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GUoVe025030; Sat, 5 Feb 2005 08:30:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GUoUe025029; Sat, 5 Feb 2005 08:30:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GUnA7025004 for ; Sat, 5 Feb 2005 08:30:49 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j15GSlHa026592; Sat, 5 Feb 2005 16:28:53 GMT In-Reply-To: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> References: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-18-464708151; protocol="application/pkcs7-signature" Message-Id: Cc: atom-syntax@imc.org From: Graham Subject: Re: PaceRepeatIdInDocument posted Date: Sat, 5 Feb 2005 16:28:46 +0000 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-18-464708151 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 4:18 pm, Antone Roundy wrote: > 1. In order to show the revision history of a particular entry, > multiple revisions of the entry must be able to appear in the same > document. But "must" we have this facility? > 2. Changing the atom:id of the entry with each revision would > severly reduce the duplicate detection value of atom:id. I don't think anyone's proposed this. -1 Graham --Apple-Mail-18-464708151 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MTYyODQ3WjAjBgkqhkiG9w0BCQQxFgQU5WoVG9MMH0MWIPgyYSERVMXD QOsweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAe1d/qZxZLH7by9uGLS+JrkhY V20DFo7bZCgl7AEq4oPkBQw3PBxYoS5MBlxKFPSoHgxFRQpINILg/gtmlRASUfpJgGG2oKnemSSL RYDW+0dWjp6ilWdlrfiOe1rmgUSQPlJ3+KgFmiIDSesHXG6leyebm0yDv+znTY8dQo1g4jtPmizi GQnZMepmuzQmd5uCCDi1317CLbh32CIGQK+L6v5dLuB803DLWDLCipXJsPrC9zOl7CSgvMxnAEgC pyZBUOJFPZpzpf2c2CpkUa4Mq2l0zhqrTHECu21EoKlu1DulcdS93xhybQV7KcCtpwki4Z9wHMiU 9fo7a/L9KdItDAAAAAAAAA== --Apple-Mail-18-464708151-- From owner-atom-syntax@mail.imc.org Sat Feb 5 11:49:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14069 for ; Sat, 5 Feb 2005 11:49:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Gg2RW032967; Sat, 5 Feb 2005 08:42:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Gg25S032966; Sat, 5 Feb 2005 08:42:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Gg1QX032959 for ; Sat, 5 Feb 2005 08:42:01 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j15Gg1Vu010992 for ; Sat, 5 Feb 2005 09:42:01 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG000UH6E0ST@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 09:42:01 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG000GT6E07R@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 09:42:00 -0700 (MST) Date: Sat, 05 Feb 2005 08:42:12 -0800 From: Tim Bray Subject: Re: Posted PaceEntryOrder (was Entry order) In-reply-to: <3f1451f505020506265ce98c47@mail.gmail.com> To: Joe Gregorio Cc: Atom Syntax , Mark Nottingham , David Powell Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: > On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham > wrote: >> This specification assigns no significance to the order of atom:entry >> elements within an Atom Feed Document. Atom Processors MAY present >> entries in any order, unless a specific ordering is required by an >> extension. > > """The order of atom:entry elements is typically in reverse > chronological order, though feeds MAY be constructed > with entries in any order, and this specification assigns > no significance to the order of atom:entry > elements within an Atom Feed Document.""" I'm +1 on both Mark and Joe's version, slightly stronger on Joe's because I don't think we need drag extensions in. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 11:50:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14122 for ; Sat, 5 Feb 2005 11:50:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GeSHJ031777; Sat, 5 Feb 2005 08:40:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GeSmp031776; Sat, 5 Feb 2005 08:40:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GeQRP031757 for ; Sat, 5 Feb 2005 08:40:27 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j15GeQVu009886 for ; Sat, 5 Feb 2005 09:40:26 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG001TK6BDGK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 09:40:26 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG000AN6BD87@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 09:40:25 -0700 (MST) Date: Sat, 05 Feb 2005 08:40:31 -0800 From: Tim Bray Subject: Re: Entry order In-reply-to: <1f2ed5cd05020505361047e69d@mail.gmail.com> To: Danny Ayers Cc: bob@wyman.us, Atom Syntax , David Powell Message-id: <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> <1f2ed5cd05020505361047e69d@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote: > > On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman wrote: > >>>> Ordering of the element children of atom:feed element MUST NOT be >>>> considered significant. > > +1. +1 - I don't care whether we say "MUST NOT", or the other wording floating around about "this specification assigns no semantics", but I am 100% against assigning any meaning to the order in which things appear in the feed. Every aggregator I've used allows you to sort them on any old column, and I totally can't think of a reasonable use-case in which preserving the feed order matters. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 12:03:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14907 for ; Sat, 5 Feb 2005 12:03:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GuRqm033916; Sat, 5 Feb 2005 08:56:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GuR0Y033915; Sat, 5 Feb 2005 08:56:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GuQ2e033896 for ; Sat, 5 Feb 2005 08:56:27 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j15Gtgvs002488; Sat, 5 Feb 2005 16:55:42 GMT In-Reply-To: <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> <1f2ed5cd05020505361047e69d@mail.gmail.com> <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-19-466323662; protocol="application/pkcs7-signature" Message-Id: <8c33b3728daf005e7c6b3540865b82d7@mac.com> Cc: "'Atom Syntax'" From: Graham Subject: Re: Entry order Date: Sat, 5 Feb 2005 16:55:42 +0000 To: Tim Bray X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-19-466323662 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 4:40 pm, Tim Bray wrote: > I totally can't think of a reasonable use-case in which preserving the > feed order matters. - The Macintouch feed is ordered in the same way as the home page, and makes no sense viewed chronologically - The BBC News feeds have the most important stories first and are much more readable and useful with the order preserved. etc etc You're shockingly small-minded sometimes Tim. Graham --Apple-Mail-19-466323662 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MTY1NTQyWjAjBgkqhkiG9w0BCQQxFgQUC+ZTLEbFgYVUJAwRogjuNZqI pZwweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAOCn4bm1OXAKHH3dLynMCbR/7 hqK39loRGb5uIHo5noqqb0x7kUO+LEu52xzCQB2uaNaWwkJnJ9UNz4T2+HCodfyRSmgt3s0Swbl3 RqTHu/BKFg6ti7es4XdI9iAvOSx2R/P5VgafSwrVTEnEGZ6MZjZ3al6oFdxjWmMLxQbv7KzfvM51 fz8d8Zg9v6OOEhggJYYUxZFLFi4feErxjI5oQ/pLeGCXZAtaPB9AnpanVqGS2T0nYg8qnEjeCh3a AeVZ0QwZuplgsjti+HG5peUNDFS2tnLyj+xKTN5Ksd0/5cZ67LlXLkEvI5AltJ/3xaN4kfXroqlz 1lUe60GfZisaUAAAAAAAAA== --Apple-Mail-19-466323662-- From owner-atom-syntax@mail.imc.org Sat Feb 5 12:05:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15000 for ; Sat, 5 Feb 2005 12:05:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15H0QRY034317; Sat, 5 Feb 2005 09:00:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15H0Qll034316; Sat, 5 Feb 2005 09:00:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15H0PYn034303 for ; Sat, 5 Feb 2005 09:00:26 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 62963 messnum 5046047 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 5 Feb 2005 17:00:17 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail04.svc.cra.dublin.eircom.net (qp 62963) with SMTP; 5 Feb 2005 17:00:17 -0000 Message-ID: <4204FB9C.1080406@dehora.net> Date: Sat, 05 Feb 2005 17:00:12 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: >> 2. Changing the atom:id of the entry with each revision would >> severly reduce the duplicate detection value of atom:id. > > > I don't think anyone's proposed this. > > -1 -1 also. I think we'd do better to focus on the specification text for id - that will be much more effective than adding qualifying text. I think it falls under editorial work and requires no pace. cheers Bill From owner-atom-syntax@mail.imc.org Sat Feb 5 12:05:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15018 for ; Sat, 5 Feb 2005 12:05:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GxUb1034242; Sat, 5 Feb 2005 08:59:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GxUAD034241; Sat, 5 Feb 2005 08:59:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GxUUR034205 for ; Sat, 5 Feb 2005 08:59:30 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050205165924014003d89ie>; Sat, 5 Feb 2005 16:59:25 +0000 Date: Sat, 5 Feb 2005 09:59:23 -0700 Subject: Re: Posted PaceEntryOrder (was Entry order) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <49431A9E-7797-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 09:42 AM, Tim Bray wrote: > On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: >> On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham >> wrote: >>> This specification assigns no significance to the order of atom:entry >>> elements within an Atom Feed Document. Atom Processors MAY present >>> entries in any order, unless a specific ordering is required by an >>> extension. >> >> """The order of atom:entry elements is typically in reverse >> chronological order, though feeds MAY be constructed >> with entries in any order, and this specification assigns >> no significance to the order of atom:entry >> elements within an Atom Feed Document.""" > > I'm +1 on both Mark and Joe's version, slightly stronger on Joe's > because I don't think we need drag extensions in. -Tim > I like Joe's very much--it reads with perfect clarity and I think it says all that needs to be said on the subject. From owner-atom-syntax@mail.imc.org Sat Feb 5 12:08:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15144 for ; Sat, 5 Feb 2005 12:07:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15H1VPo034388; Sat, 5 Feb 2005 09:01:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15H1VDa034387; Sat, 5 Feb 2005 09:01:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15H1Uqv034376 for ; Sat, 5 Feb 2005 09:01:31 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j15H0vlB003890; Sat, 5 Feb 2005 17:00:57 GMT In-Reply-To: <3f1451f505020506265ce98c47@mail.gmail.com> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-20-466638941; protocol="application/pkcs7-signature" Message-Id: <1b0843f0d1b7011cfcc820ead8266a14@mac.com> Cc: Atom Syntax , Mark Nottingham , David Powell From: Graham Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 17:00:57 +0000 To: Joe Gregorio X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-20-466638941 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 2:26 pm, Joe Gregorio wrote: How is any of this useful in a normative document? > """The order of atom:entry elements is typically in reverse > chronological order What does this tell who? > though feeds MAY be constructed with entries in any order This is just about useful. > and this specification assigns no significance to the order of > atom:entry > elements within an Atom Feed Document. I have no idea what this sentence is meant to tell people. I think you're trying to say that nothing can be inferred from the order entries appear in, but why you (and apparently several others) choose to say it in such a roundabout way is beyond me. Graham --Apple-Mail-20-466638941 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGDDCCAsUw ggIuoAMCAQICAwuqUzANBgkqhkiG9w0BAQQFADBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhh d3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVt YWlsIElzc3VpbmcgQ0EwHhcNMDQwMjA3MjIzNDA1WhcNMDUwMjA2MjIzNDA1WjA+MR8wHQYDVQQD ExZUaGF3dGUgRnJlZW1haWwgTWVtYmVyMRswGQYJKoZIhvcNAQkBFgxkdGNkQG1hYy5jb20wggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDgdw59wBv8wz4jyS4cFojV3xKfHDvWRVMdfeZ2 epV1MR83KbIpif5RH+iY9xpss9v1IGjqlEt4IhbT5RnC1FxHd+RvQ60oKRXj9F2mkU7m9bu+CXsi ejSGa6MgJzo1pvK2khEgHHpDQqhf9ILfYn4XFBxeS1/6E7aISVrTgOX2lt7TwHrfg7WwDm58yQOV fDoGwECE74WFNEfRMxavURZ5AGnNWeTBVFPDe/BbXSvD+hEoiHvP10ZRL0z4B4JMjdEqoIHFT/Er utvI6dSmLfSaERmsDT29UkbyXGEsVvsaKhjJxVT7yiAhQtwclUWTA6blm6f3ZY7TZpRt3MAr+0Qp AgMBAAGjKTAnMBcGA1UdEQQQMA6BDGR0Y2RAbWFjLmNvbTAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3 DQEBBAUAA4GBABE9NhMrR8+MJrXd+rwuR+v2EIwBgeMWqoPUVThtNoV3W0D6o1UIDFGpSz9AgqFO LDU4hWUh4yrtsR4F2gULnvkdzsIv4ttEqbcJVC1ckCemjTtE9uS3d2eJzj8XeYJEaOGHNPkDPvCG E++wSGS6I0Zyuzcuobneq1b4gTxKLYeeMIIDPzCCAqigAwIBAgIBDTANBgkqhkiG9w0BAQUFADCB 0TELMAkGA1UEBhMCWkExFTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3du MRowGAYDVQQKExFUaGF3dGUgQ29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2 aWNlcyBEaXZpc2lvbjEkMCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJ KoZIhvcNAQkBFhxwZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAzMDcxNzAwMDAwMFoX DTEzMDcxNjIzNTk1OVowYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5n IChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENB MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDEpjxVc1X7TrnKmVoeaMB1BHCd3+n/ox7svc31 W/Iadr1/DDph8r9RzgHU5VAKMNcCY1osiRVwjt3J8CuFWqo/cVbLrzwLB+fxH5E2JCoTzyvV84J3 PQO+K/67GD4Hv0CAAmTXp6a7n2XRxSpUhQ9IBH+nttE8YQRAHmQZcmC3+wIDAQABo4GUMIGRMBIG A1UdEwEB/wQIMAYBAf8CAQAwQwYDVR0fBDwwOjA4oDagNIYyaHR0cDovL2NybC50aGF3dGUuY29t L1RoYXd0ZVBlcnNvbmFsRnJlZW1haWxDQS5jcmwwCwYDVR0PBAQDAgEGMCkGA1UdEQQiMCCkHjAc MRowGAYDVQQDExFQcml2YXRlTGFiZWwyLTEzODANBgkqhkiG9w0BAQUFAAOBgQBIjNFQg+oLLswN o2asZw9/r6y+whehQ5aUnX9MIbj4Nh+qLZ82L8D0HFAgk3A8/a3hYWLD2ToZfoSxmRsAxRoLgnSe JVCUYsfbJ3FXJY3dqZw5jowgT2Vfldr394fWxghOrvbqNOUQGls1TXfjViF4gtwhGTXeJLHTHUb/ XV9lTzGCAucwggLjAgEBMGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0 aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5n IENBAgMLqlMwCQYFKw4DAhoFAKCCAVMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMDUwMjA1MTcwMDU4WjAjBgkqhkiG9w0BCQQxFgQUdYLpkgc0HpADNj0Q40JXQFl6 3kcweAYJKwYBBAGCNxAEMWswaTBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1 bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3Vp bmcgQ0ECAwuqUzB6BgsqhkiG9w0BCRACCzFroGkwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRo YXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBJc3N1aW5nIENBAgMLqlMwDQYJKoZIhvcNAQEBBQAEggEAWGdKpBhVFuu5BlXu1tQkddZ9 iGsE3DI6Q3wnWyI9ekk9TlO6F39y1tRxVExxqT0/ryoYqzWEVrtdctExUb9OMiSfS+XH2vOoUwVx SbkgpTMy4PwdtwwZuXyGvwpW7uECeAzTS0xsajr2jYveaJuYgl8U30ZhNhnvzeTA4Np2HwZRSelT yNqUJfn2jpJoua+EpREwyNgmMw11/RL5xtO8eaOksdSavHi/QHHAhz3hOdcnbPYiwaQj9WDEal/4 p1AguJu33Lcrv8dwsKQ00XpQnAunE6tb2n/rkbcIHKXbliJ88SDfeFbyi0pyv/0evqDUeoptwJNP u9w/i7JlTkl9DgAAAAAAAA== --Apple-Mail-20-466638941-- From owner-atom-syntax@mail.imc.org Sat Feb 5 12:08:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15174 for ; Sat, 5 Feb 2005 12:08:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GxHp9034188; Sat, 5 Feb 2005 08:59:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15GxHnj034187; Sat, 5 Feb 2005 08:59:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15GxGPG034180 for ; Sat, 5 Feb 2005 08:59:17 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 92AFB4F431; Sat, 5 Feb 2005 11:59:16 -0500 (EST) Date: Sat, 5 Feb 2005 11:59:16 -0500 From: Dan Brickley To: Atom Syntax Subject: Re: Entry order Message-ID: <20050205165916.GD23557@homer.w3.org> References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> <1f2ed5cd05020505361047e69d@mail.gmail.com> <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.6+20040907i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Tim Bray [2005-02-05 08:40-0800] > > > On Feb 5, 2005, at 5:36 AM, Danny Ayers wrote: > > > > >On Thu, 3 Feb 2005 23:21:50 -0500, Bob Wyman wrote: > > > >>>>Ordering of the element children of atom:feed element MUST NOT be > >>>>considered significant. > > > >+1. > > +1 - I don't care whether we say "MUST NOT", or the other wording > floating around about "this specification assigns no semantics", but I > am 100% against assigning any meaning to the order in which things > appear in the feed. +1 Although I could've lived with order being declared meaningful. The worst case is when it isn't clear whether ordering info must be preserved. Aside: sometimes in RSS1 item order relates to characteristics of the things described by the documents in the feed, rather than the docs directly (eg. job adverts, upcoming movies, ...). Dan Dan From owner-atom-syntax@mail.imc.org Sat Feb 5 12:21:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16044 for ; Sat, 5 Feb 2005 12:21:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HDfZF035707; Sat, 5 Feb 2005 09:13:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HDfeq035706; Sat, 5 Feb 2005 09:13:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HDeAT035698 for ; Sat, 5 Feb 2005 09:13:40 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxTUx-00022e-Dh; Sat, 05 Feb 2005 17:13:31 +0000 Message-ID: <4204FEBC.1000002@franklinmint.fm> Date: Sat, 05 Feb 2005 12:13:32 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Joe Gregorio , Atom Syntax , Mark Nottingham , David Powell Subject: Re: Posted PaceEntryOrder (was Entry order) References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > I'm +1 on both Mark and Joe's version, slightly stronger on Joe's > because I don't think we need drag extensions in. "This specification assigns no significance to the order of atom:entry elements within an Atom Feed Document. Atom Processors MAY present entries in any order, including document order." Extensions don't get to make demands on generic Atom processors. Lots feeds will consist of entris with the same date, and lots of aggregators will just show things in the order the SAX parser sent it. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 12:32:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16457 for ; Sat, 5 Feb 2005 12:32:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HPIV8036496; Sat, 5 Feb 2005 09:25:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HPIZn036495; Sat, 5 Feb 2005 09:25:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HPHxH036488 for ; Sat, 5 Feb 2005 09:25:17 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxTgI-0002At-62; Sat, 05 Feb 2005 17:25:14 +0000 Message-ID: <4205017B.4060300@franklinmint.fm> Date: Sat, 05 Feb 2005 12:25:15 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> In-Reply-To: <95A75350-7791-11D9-9564-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > 1. In order to show the revision history of a particular entry, > multiple revisions of the entry must be able to appear in the same > document. > 2. Changing the atom:id of the entry with each revision would severly > reduce the duplicate detection value of atom:id. > -1. RSS1.0: "{item_uri} must be unique with respect to any other rdf:about attributes in the RSS document and is a URI which identifies the item." RSS1.1: "The value of each rdf:about attribute must be unique to the document" RSS2.0: Doesn't say anything about it (surprise!). But, I don't think I've ever seen a document that duplicated them with your intended semantics. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 12:33:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16493 for ; Sat, 5 Feb 2005 12:33:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HOU2m036453; Sat, 5 Feb 2005 09:24:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HOU99036452; Sat, 5 Feb 2005 09:24:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HOUFx036441 for ; Sat, 5 Feb 2005 09:24:30 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050205172424014003i4u6e>; Sat, 5 Feb 2005 17:24:25 +0000 Date: Sat, 5 Feb 2005 10:24:23 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <4204FB9C.1080406@dehora.net> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j15HOUFx036446 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, February 5, 2005, at 10:00 AM, Bill de hÓra wrote: > Graham wrote: > >>> 2. Changing the atom:id of the entry with each revision would >>> severly reduce the duplicate detection value of atom:id. >> I don't think anyone's proposed this. >> -1 Wrong: http://www.imc.org/atom-syntax/mail-archive/msg13161.html > -1 also. I think we'd do better to focus on the specification text for > id - that will be much more effective than adding qualifying text. I > think it falls under editorial work and requires no pace. > I have no idea what you mean by this comment. Part of the purpose of the Pace does seek to improve on the specification text for id (see the abstract, and compare the proposed text to the current draft) for the benefit of those who don't think it's perfectly clear if you don't refuse to keep reading after the first sentence. Do you think the proposed change doesn't help? If not, how about a counter suggestion or at least something more concrete than "...that will be much more effective than adding qualifying text. I think it falls under editorial work and requires no pace." Do you not think that we need to specify whether or not multiple instances of a resource can appear in a single document (with the same atom:id)? Language specifying that they may is hardly mere editorial work--it requires a decision by the working group to decide whether we do want to allow it or not. Warning publishers that consumers might not display each version of a resource if the do choose to include multiple revisions in a single document might be considered editorial work, but there's certainly no reason not to include such language in a proposal whose primary purpose is to clarify whether putting multiple revisions in the document is allowed. From owner-atom-syntax@mail.imc.org Sat Feb 5 12:36:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16572 for ; Sat, 5 Feb 2005 12:36:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HRvT2036710; Sat, 5 Feb 2005 09:27:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HRvG0036708; Sat, 5 Feb 2005 09:27:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gps07-c1107.vodafone.net (mailer.vodafone.net [212.183.156.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HRuJq036690 for ; Sat, 5 Feb 2005 09:27:57 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from Inbox (127.0.0.1) by gps07-c1107.vodafone.net (NPlex 6.0.021C4.14) id 41FE0DEE00004910; Sat, 5 Feb 2005 17:27:47 +0000 Message-ID: <41FE0DEE00004910@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net) From: "David Powell" To: Cc: Subject: Re: Proof-of-concept RDF mapping for Atom Date: Sat, 5 Feb 2005 17:27:43 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1432.1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think it is a problem, I'm not near a PC this weekend though. I'll try to write a Pace on Sunday night that will make it explicit what xml:lang applies to. >Have you had any more luck with this part of the mapping? Is this a >problem with the current Atom syntax if not? > >Henry Story > >On 28 Jan 2005, at 22:27, David Powell wrote: >> I think it >> handles everything except for xml:lang - I'm not sure what's happening >> with xml:lang at the moment - but it should be possible to add it in a >> similar way to xml:base. From owner-atom-syntax@mail.imc.org Sat Feb 5 12:36:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16626 for ; Sat, 5 Feb 2005 12:36:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HRvx0036711; Sat, 5 Feb 2005 09:27:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HRvef036709; Sat, 5 Feb 2005 09:27:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from gps07-c1107.vodafone.net (mailer.vodafone.net [212.183.156.227]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HRuuE036685 for ; Sat, 5 Feb 2005 09:27:57 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from Inbox (127.0.0.1) by gps07-c1107.vodafone.net (NPlex 6.0.021C4.14) id 41FE0DEE0000490F; Sat, 5 Feb 2005 17:27:39 +0000 Message-ID: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net) From: "David Powell" To: , Cc: Subject: Re: Call for final Paces for consideration: deadline imminent Date: Sat, 5 Feb 2005 17:27:34 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft MimeOLE V5.00.1432.1 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >I disagree, as I've said before. The only literal interpretation is >that you can't serve the same entry twice with the same id. We know it >doesn't mean that, but the spec just doesn't define in which axis >"unique" is meant to apply. I think that the problem is that the term 'entry' is used to refer to two different concepts. An entry id is identifying the underlying entry resource. But something like an entry title, I would think of as a property of the 'entry instance'. Currently we don't distinguish between entries and entry instances, and I think that this creates a lot of ambiguity. Although we could keep the model we have (let's call it the 'mutable entries' model), it isn’t clear on a number of issues. Eg, if an old version of an entry has some property that isn’t present in a newer version, does that property still apply to the new instance? The answer is presumably 'no' but it isn't obvious from the spec. Under a 'multiple instances' model, it would be implicit. -- Dave From owner-atom-syntax@mail.imc.org Sat Feb 5 12:51:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17409 for ; Sat, 5 Feb 2005 12:51:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HfRxP037988; Sat, 5 Feb 2005 09:41:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HfRv4037987; Sat, 5 Feb 2005 09:41:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HfQ1I037975 for ; Sat, 5 Feb 2005 09:41:27 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020517412101100cf2g4e>; Sat, 5 Feb 2005 17:41:21 +0000 Date: Sat, 5 Feb 2005 10:41:19 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4205017B.4060300@franklinmint.fm> Message-Id: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 10:25 AM, Robert Sayre wrote: > Antone Roundy wrote: >> >> 1. In order to show the revision history of a particular entry, >> multiple revisions of the entry must be able to appear in the same >> document. >> 2. Changing the atom:id of the entry with each revision would >> severly reduce the duplicate detection value of atom:id. > > -1. > > RSS1.0: "{item_uri} must be unique with respect to any other rdf:about > attributes in the RSS document and is a URI which identifies the > item." > > RSS1.1: "The value of each rdf:about attribute must be unique to the > document" Neither of these is equivalent to atom:id--according to this text, the {item_uri} and rdf:about for a particular item could change each time you transmit the feed. Whether we accept this Pace or not, that is not what is intend for atom:id. Could you explain how these are in any way relevant to this Pace? > RSS2.0: Doesn't say anything about it (surprise!). But, I don't think > I've ever seen a document that duplicated them with your intended > semantics. Part of our charter is to define a format suitable for archiving feeds. A number of people in the working group have expressed a desire to be able to archive the revision history of an entry--not just the latest version--which is a fairly natural thing to want to do with an archive format. That's not something any RSS version has attempted as far as I'm aware. Therefore, if we wish to accomplish this goal, we need to do things that no RSS version ever did. Past history isn't necessarily a valid guide in this case. From owner-atom-syntax@mail.imc.org Sat Feb 5 12:58:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17750 for ; Sat, 5 Feb 2005 12:58:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HmlqW038506; Sat, 5 Feb 2005 09:48:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Hmlj9038504; Sat, 5 Feb 2005 09:48:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Hmklt038482 for ; Sat, 5 Feb 2005 09:48:46 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 5417D51A12; Sat, 5 Feb 2005 12:48:39 -0500 (EST) In-Reply-To: <3f1451f505020506265ce98c47@mail.gmail.com> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax , David Powell X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Sat, 5 Feb 2005 09:48:32 -0800 To: Joe Gregorio X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 5, 2005, at 6:26 AM, Joe Gregorio wrote: > On Thu, 3 Feb 2005 20:25:50 -0800, Mark Nottingham > wrote: >> >> My preference would be something like >> >> This specification assigns no significance to the order of atom:entry >> elements within an Atom Feed Document. Atom Processors MAY present >> entries in any order, unless a specific ordering is required by an >> extension. >> >> (I.e., I could come up with the UseLexicalOrdering extension, and >> require processors to understand it to use the feed, assuming our >> extensibility model supports that, which I very much hope it will). > > -1 Atom is a Must Ignore format. What does that mean? SOAP is a "Must Ignore format," but it also has a way of saying that you have to understand a particular extension; as I said before, this is one of the big problems with HTTP. mustUnderstand should be used sparingly, but sometimes it's necessary. -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sat Feb 5 12:59:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17781 for ; Sat, 5 Feb 2005 12:59:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HmlEr038505; Sat, 5 Feb 2005 09:48:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15HmlB7038503; Sat, 5 Feb 2005 09:48:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15HmkOS038492 for ; Sat, 5 Feb 2005 09:48:46 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id CA75451A39; Sat, 5 Feb 2005 12:48:45 -0500 (EST) In-Reply-To: <8d634a7b02a53e4ec0a314fad2c0db6c@bblfish.net> References: <419B3EC800066D22@gps05-c10d6.vodafone.net> (added by postmaster@vodafone.net) <8d634a7b02a53e4ec0a314fad2c0db6c@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9eaa8bfb5b5354e94b7cffb8d242b39f@mnot.net> Content-Transfer-Encoding: 7bit Cc: "David Powell" , X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 09:48:43 -0800 To: Henry Story X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 5, 2005, at 4:38 AM, Henry Story wrote: > You put this in terms of databases and I put the question in terms of > graphs (which if you > have an rdf database to store your triples comes to the same thing). > > And my feeling is here that we should not have to keep the sequence > numbers of the > order of the entries in the document. Very well said, with emphasis on "have to"; they shouldn't be prohibited from doing so if they want to (and I don't think you're saying otherwise). > Display order on the client will also completely depend on what the > client is trying to > do. If the client is just interested in archiving all the entries, > then any new feed > be it an old one or a new one will be of interest: it will just be > added to the database. +1 -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sat Feb 5 13:01:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17935 for ; Sat, 5 Feb 2005 13:01:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Hr7hq039150; Sat, 5 Feb 2005 09:53:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Hr7BZ039149; Sat, 5 Feb 2005 09:53:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Hr6fV039143 for ; Sat, 5 Feb 2005 09:53:06 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 98267 invoked by uid 17064); 5 Feb 2005 17:53:06 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.131.25]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 17:53:06 -0000 In-Reply-To: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net) References: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <7e5b3614bf14dd5d4499da0a94ae5702@bblfish.net> Cc: Atom Syntax From: Henry Story Subject: Re: Call for final Paces for consideration: deadline imminent Date: Sat, 5 Feb 2005 18:53:02 +0100 To: "David Powell" X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j15Hr6fV039144 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 5 Feb 2005, at 18:27, David Powell wrote: >> I disagree, as I've said before. The only literal interpretation is >> that you can't serve the same entry twice with the same id. We know it >> doesn't mean that, but the spec just doesn't define in which axis >> "unique" is meant to apply. > > I think that the problem is that the term 'entry' is used to refer to > two different concepts. > > An entry id is identifying the underlying entry resource. > > But something like an entry title, I would think of as a property of > the 'entry instance'. > > Currently we don't distinguish between entries and entry instances, > and I think that this creates a lot of ambiguity. I agree with this analysis. But I think one can deal with it. A simple OWL ontology would make these things very clear. > Although we could keep the model we have (let's call it > the 'mutable entries' model), it isn’t clear on a number of issues. > Eg, if an old version of an entry has some property that isn’t > present in a newer version, does that property still apply to the new > instance? The answer is presumably 'no' but it isn't obvious from the > spec. Under a 'multiple instances' model, it would be implicit. It is easiest if one starts off deciding that no properties get inherited. Some properties do seem to clearly require inheritance such as the author, as one would expect all the versions of an entry to have the same author. But the amount of debating that this would require would not be worth the effort. The id property does the job very nicely and inconspicuously. At one point I had thought that properties such as author should be directly attached to the id construct, since they are immutable. But then one gets into problems of which are essential and which non essential properties... Henry Story > > -- > Dave > From owner-atom-syntax@mail.imc.org Sat Feb 5 13:12:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18778 for ; Sat, 5 Feb 2005 13:12:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15I292o039782; Sat, 5 Feb 2005 10:02:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15I29wR039781; Sat, 5 Feb 2005 10:02:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15I28Q0039775 for ; Sat, 5 Feb 2005 10:02:08 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j15I28dt007322 for ; Sat, 5 Feb 2005 11:02:08 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG000Y8A3JSQ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 11:02:07 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG005WZA3IUK@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 11:02:07 -0700 (MST) Date: Sat, 05 Feb 2005 10:02:16 -0800 From: Tim Bray Subject: PaceExtensionConstruct To: Atom Syntax Message-id: <121337daed5f48c6c8b6a405c0a10ad3@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT -1 Consider this sentence: "The construct can be interpreted as a simple property of its Subject. The pair consisting of the namespace-URI of the element and the local name of the element can be interpreted as the name of the property. " It will make NO SENSE WHATEVER to someone who isn't hip to the RDF nudge-nudge wink-wink. The term "property" is not defined and thus this provides no useful information to implementors. A vastly better approach would be to say: "In order to facilitate understanding Atom data in RDF terms, elements from non-Atom namespaces may only appear as children of Person constructs, atom:head, and atom:entry." Then in an entirely separate document which that proportion of the world that simply doesn't care about RDF can ignore entirely, you can carefully define exactly what you mean in RDF graph terms without having to hint around undefined terms like "property". I don't think including this in Atom would cause any harm, so I could live with it, but I think it fails to meet the goal of providing any benefit to the vast majority of implementors and should be left out. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 13:23:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19567 for ; Sat, 5 Feb 2005 13:23:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ICTma040551; Sat, 5 Feb 2005 10:12:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15ICTUT040550; Sat, 5 Feb 2005 10:12:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ICSt5040544 for ; Sat, 5 Feb 2005 10:12:28 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 15466 invoked by uid 17064); 5 Feb 2005 18:12:27 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.131.25]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 18:12:27 -0000 In-Reply-To: <9eaa8bfb5b5354e94b7cffb8d242b39f@mnot.net> References: <419B3EC800066D22@gps05-c10d6.vodafone.net> (added by postmaster@vodafone.net) <8d634a7b02a53e4ec0a314fad2c0db6c@bblfish.net> <9eaa8bfb5b5354e94b7cffb8d242b39f@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <17207f83d8a37be3e1cf30ef84290de1@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: Posted PaceEntryOrder (was Entry order) Date: Sat, 5 Feb 2005 19:12:22 +0100 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 18:48, Mark Nottingham wrote: > On Feb 5, 2005, at 4:38 AM, Henry Story wrote: >> You put this in terms of databases and I put the question in terms of >> graphs (which if you >> have an rdf database to store your triples comes to the same thing). >> >> And my feeling is here that we should not have to keep the sequence >> numbers of the >> order of the entries in the document. > > Very well said, with emphasis on "have to"; they shouldn't be > prohibited from doing so if they want to (and I don't think you're > saying otherwise). yes, but perhaps if these were to be kept in the database they should not be saved as a direct property of the entry, but as a relation that the entry has to an event of document fetching. I am thinking here about the parallel with search engine results. The results you get from a search engine will be ordered in some way. This is inevitable. But one should be careful not to think that generally the results have any intrinsic meaning. Certainly not intrinsic in the sense that these would usefully be thought of as being properties of the web pages themselves. They are rather a factual statement about an order given by the search engine when you made a request at a certain time. Continuing along this line of thought, if you made a request to your favorite search engine to return its results in last changed order (and perhaps narrowed your request down to a specific site) then the order of the results could help you come to conclusions much faster. If could save you for example having to search through all the results if you were only looking for entries that had changed in the last day. Once you reached results that had changed before that, you would be sure that all other results were no longer relevant. I think this is probably what Roy fielding meant recently when he spoke about the difference between the model and the interaction model. In any case this should be something that one specifies at the protocol level. Henry Story > > >> Display order on the client will also completely depend on what the >> client is trying to >> do. If the client is just interested in archiving all the entries, >> then any new feed >> be it an old one or a new one will be of interest: it will just be >> added to the database. > > +1 Cool sometimes I also get +1 :-) > > -- > Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sat Feb 5 13:29:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20145 for ; Sat, 5 Feb 2005 13:29:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IIBEx041036; Sat, 5 Feb 2005 10:18:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15IIBwS041035; Sat, 5 Feb 2005 10:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IIAkJ041029 for ; Sat, 5 Feb 2005 10:18:10 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j15IIAdt016868 for ; Sat, 5 Feb 2005 11:18:10 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG000LSAU9ST@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 11:18:10 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG005TJAU8UN@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 11:18:09 -0700 (MST) Date: Sat, 05 Feb 2005 10:18:18 -0800 From: Tim Bray Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] In-reply-to: To: Mark Nottingham Cc: Joe Gregorio , Atom Syntax , David Powell Message-id: <9869d677801b19b5202633f3cf1bfd1f@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: > What does that mean? SOAP is a "Must Ignore format," but it also has a > way of saying that you have to understand a particular extension; as I > said before, this is one of the big problems with HTTP. mustUnderstand > should be used sparingly, but sometimes it's necessary. Unfortunately my PaceMustUnderstandElement was shouted down by a howling mob of WG members with torches and pitchforks. Sigh. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 13:30:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20198 for ; Sat, 5 Feb 2005 13:30:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IL69a041261; Sat, 5 Feb 2005 10:21:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15IL6l3041260; Sat, 5 Feb 2005 10:21:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15IL5is041231 for ; Sat, 5 Feb 2005 10:21:06 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 37696 messnum 2833157 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 5 Feb 2005 18:20:59 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail07.svc.cra.dublin.eircom.net (qp 37696) with SMTP; 5 Feb 2005 18:20:59 -0000 Message-ID: <42050E86.3040205@dehora.net> Date: Sat, 05 Feb 2005 18:20:54 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: >> -1 also. I think we'd do better to focus on the specification text for >> id - that will be much more effective than adding qualifying text. I >> think it falls under editorial work and requires no pace. >> > I have no idea what you mean by this comment. I mean this: 1. I believe the editors can and will fix the specification text to be more precise. 2. I believe 1 does not require a pace. > Part of the purpose of > the Pace does seek to improve on the specification text for id (see the > abstract, and compare the proposed text to the current draft) for the > benefit of those who don't think it's perfectly clear if you don't > refuse to keep reading after the first sentence. Do you think the > proposed change doesn't help? If not, how about a counter suggestion or > at least something more concrete than "...that will be much more > effective than adding qualifying text. I think it falls under editorial > work and requires no pace." > > Do you not think that we need to specify whether or not multiple > instances of a resource can appear in a single document (with the same > atom:id)? You don't know how far I've read into the pace, and asking me loaded or presumptive questions won't persuade me to change my mind. cheers Bill From owner-atom-syntax@mail.imc.org Sat Feb 5 13:33:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20385 for ; Sat, 5 Feb 2005 13:33:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IMw0r041431; Sat, 5 Feb 2005 10:22:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15IMwTE041430; Sat, 5 Feb 2005 10:22:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IMvMX041424 for ; Sat, 5 Feb 2005 10:22:57 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxUa6-0002m8-1u; Sat, 05 Feb 2005 18:22:54 +0000 Message-ID: <42050EFC.9010207@franklinmint.fm> Date: Sat, 05 Feb 2005 13:22:52 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: Atom Syntax Subject: Re: PaceExtensionConstruct References: <121337daed5f48c6c8b6a405c0a10ad3@sun.com> In-Reply-To: <121337daed5f48c6c8b6a405c0a10ad3@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > -1 > > Consider this sentence: > "The construct can be interpreted as a simple property of its > Subject. The pair consisting of the namespace-URI of the element > and the local name of the element can be interpreted as the name of > the property. " > > It will make NO SENSE WHATEVER to someone who isn't hip to the RDF > nudge-nudge wink-wink. The term "property" is not defined and thus this > provides no useful information to implementors. A vastly better > approach would be to say:" The text in PaceHeadless use less hip language to describe things: "The element can be interpreted as a simple property of the parent element that encloses it." It's just name/value pairs, no understanding of RDF required. This is the approach that a vast majority of extensions to RSS1 and RSS2 take. It's worth preserving and standardizing. It also helps WebDAV and CMSes convert these things to their notion of name/value pairs and properties. It would also be a big help when extending the protocol, making it simpler to use fields that aren't built in to the server. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 13:33:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20411 for ; Sat, 5 Feb 2005 13:33:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IOPRe041619; Sat, 5 Feb 2005 10:24:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15IOPVg041618; Sat, 5 Feb 2005 10:24:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15IOOUJ041611 for ; Sat, 5 Feb 2005 10:24:24 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id D2AC751A65; Sat, 5 Feb 2005 13:24:23 -0500 (EST) In-Reply-To: <9869d677801b19b5202633f3cf1bfd1f@sun.com> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> <9869d677801b19b5202633f3cf1bfd1f@sun.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Joe Gregorio , Atom Syntax , David Powell X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Sat, 5 Feb 2005 10:24:17 -0800 To: Tim Bray X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sigh indeed. We have only one chance to do this. This was one of the big advantages that I was looking for Atom to have over RSS... On Feb 5, 2005, at 10:18 AM, Tim Bray wrote: > On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: > >> What does that mean? SOAP is a "Must Ignore format," but it also has >> a way of saying that you have to understand a particular extension; >> as I said before, this is one of the big problems with HTTP. >> mustUnderstand should be used sparingly, but sometimes it's >> necessary. > > Unfortunately my PaceMustUnderstandElement was shouted down by a > howling mob of WG members with torches and pitchforks. Sigh. -Tim -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sat Feb 5 13:37:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20605 for ; Sat, 5 Feb 2005 13:37:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ISU68041953; Sat, 5 Feb 2005 10:28:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15ISUcJ041952; Sat, 5 Feb 2005 10:28:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15IST6h041937 for ; Sat, 5 Feb 2005 10:28:30 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 71008 messnum 365596 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 5 Feb 2005 18:28:24 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail05.svc.cra.dublin.eircom.net (qp 71008) with SMTP; 5 Feb 2005 18:28:24 -0000 Message-ID: <42051043.6010609@dehora.net> Date: Sat, 05 Feb 2005 18:28:19 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "'Atom Syntax'" Subject: Re: Entry order References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> <1f2ed5cd05020505361047e69d@mail.gmail.com> <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> <8c33b3728daf005e7c6b3540865b82d7@mac.com> In-Reply-To: <8c33b3728daf005e7c6b3540865b82d7@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > On 5 Feb 2005, at 4:40 pm, Tim Bray wrote: > >> I totally can't think of a reasonable use-case in which preserving the >> feed order matters. > > > - The Macintouch feed is ordered in the same way as the home page, and > makes no sense viewed chronologically > - The BBC News feeds have the most important stories first and are much > more readable and useful with the order preserved. > etc etc > > You're shockingly small-minded sometimes Tim. Rudeness objection. cheers Bill From owner-atom-syntax@mail.imc.org Sat Feb 5 13:57:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21729 for ; Sat, 5 Feb 2005 13:57:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ImBhB043233; Sat, 5 Feb 2005 10:48:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15ImBw1043232; Sat, 5 Feb 2005 10:48:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15ImBrd043226 for ; Sat, 5 Feb 2005 10:48:11 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxUyV-00034q-CO; Sat, 05 Feb 2005 18:48:07 +0000 Message-ID: <420514E6.8050201@franklinmint.fm> Date: Sat, 05 Feb 2005 13:48:06 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> In-Reply-To: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > Neither of these is equivalent to atom:id--according to this text, the > {item_uri} and rdf:about for a particular item could change each time > you transmit the feed. Whether we accept this Pace or not, that is not > what is intend for atom:id. Could you explain how these are in any way > relevant to this Pace? > I'm sorry, that's nonsense. We don't get to make up how syndication works. I understand the thinking behind your proposal, but it *doesn't work*. > > Part of our charter is to define a format suitable for archiving feeds. Right, and breaking the feed format isn't the way to do it. Since you're advocating versioning, what are your plans for versioning the state of the feed itself? What if the title changes? It would be better to archive a series of feed documents. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 14:07:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22256 for ; Sat, 5 Feb 2005 14:07:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Iw39Q043879; Sat, 5 Feb 2005 10:58:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Iw3o4043878; Sat, 5 Feb 2005 10:58:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Iw2sh043863 for ; Sat, 5 Feb 2005 10:58:02 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020518575701300k8crde>; Sat, 5 Feb 2005 18:57:57 +0000 Date: Sat, 5 Feb 2005 11:57:56 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <42050E86.3040205@dehora.net> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j15Iw3sh043871 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Saturday, February 5, 2005, at 11:20 AM, Bill de hÓra wrote: > Antone Roundy wrote: >>> -1 also. I think we'd do better to focus on the specification text >>> for id - that will be much more effective than adding qualifying >>> text. I think it falls under editorial work and requires no pace. >>> >> I have no idea what you mean by this comment. > > I mean this: > > 1. I believe the editors can and will fix the specification text to > be more precise. > > 2. I believe 1 does not require a pace. > > >> Part of the purpose of the Pace does seek to improve on the >> specification text for id (see the abstract, and compare the proposed >> text to the current draft) for the benefit of those who don't think >> it's perfectly clear if you don't refuse to keep reading after the >> first sentence. Do you think the proposed change doesn't help? If >> not, how about a counter suggestion or at least something more >> concrete than "...that will be much more effective than adding >> qualifying text. I think it falls under editorial work and requires >> no pace." > > >> Do you not think that we need to specify whether or not multiple >> instances of a resource can appear in a single document (with the >> same atom:id)? > > You don't know how far I've read into the pace, and asking me loaded > or presumptive questions won't persuade me to change my mind. > Sometimes I think the "Rationale" sections of Paces do more harm than good because we end up discussing the authors' stated reasons for what they propose, which aren't going to be in the spec, and don't discuss the proposed text, which is. Of course, the rationale is not irrelevant--its relationship to the spec is similar to the Federalist Papers' relationship to the U.S. Constitution[1]--if a question arises over what a part of the spec means, the rationale section of the pace that introduced the spec text is a useful guide. But its definitely secondary to the proposed text. That said, yes, some imperfections may be appropriately left to the editors to address without needing paces. In this case, I respectfully disagree about whether this is a simple editorial issue. [1] The Federalist Papers is a series of of articles published under a pseudonym before the U.S. Constitution was adopted, written by Alexander Hamilton, James Madison, and John Jay, discussing the rationale for various parts of the proposed constitution. From owner-atom-syntax@mail.imc.org Sat Feb 5 14:13:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22604 for ; Sat, 5 Feb 2005 14:13:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15J0OON044289; Sat, 5 Feb 2005 11:00:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15J0O72044288; Sat, 5 Feb 2005 11:00:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15J0OxG044281 for ; Sat, 5 Feb 2005 11:00:24 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 55515 invoked by uid 17064); 5 Feb 2005 19:00:24 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.2.206]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 19:00:24 -0000 In-Reply-To: <420514E6.8050201@franklinmint.fm> References: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> <420514E6.8050201@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceRepeatIdInDocument posted Date: Sat, 5 Feb 2005 19:59:57 +0100 To: mint@franklinmint.fm X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 19:48, Robert Sayre wrote: > Antone Roundy wrote: > >> Neither of these is equivalent to atom:id--according to this text, >> the {item_uri} and rdf:about for a particular item could change each >> time you transmit the feed. Whether we accept this Pace or not, that >> is not what is intend for atom:id. Could you explain how these are >> in any way relevant to this Pace? > > I'm sorry, that's nonsense. We don't get to make up how syndication > works. I understand the thinking behind your proposal, but it *doesn't > work*. > >> Part of our charter is to define a format suitable for archiving >> feeds. > > Right, and breaking the feed format isn't the way to do it. Since > you're advocating versioning, what are your plans for versioning the > state of the feed itself? What if the title changes? It would be > better to archive a series of feed documents. Oh. I think here there are two elements to answer this: 1. A feed is not something that can be archived. This is to do with a feed properly speaking being at the interaction 2. the feed head (which is in fact just a special entry that describes the feed) can have versions just like any other entry. These can be identified as being different version of the same entry by their id attribute, just as any other entry can. Henry Story > > Robert Sayre > From owner-atom-syntax@mail.imc.org Sat Feb 5 14:20:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23057 for ; Sat, 5 Feb 2005 14:20:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15J9VXv045496; Sat, 5 Feb 2005 11:09:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15J9VUV045495; Sat, 5 Feb 2005 11:09:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15J9UIo045489 for ; Sat, 5 Feb 2005 11:09:30 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j15J9Mmo000899; Sat, 5 Feb 2005 14:09:24 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNR36538; Sat, 5 Feb 2005 14:09:20 -0500 (EST) Message-Id: <200502051909.CNR36538@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Danny Ayers'" Cc: Subject: RE: Open Comments..... Date: Sat, 5 Feb 2005 14:09:19 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULcB9Xy9HvGLZtSBCpDP5UKCfkjQAP8xAg In-Reply-To: <1f2ed5cd05020502293ca3984b@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > The motto that spontaneously emerged on this list was > "It's the Entries, stupid!" - comments and trackbacks are just > entries too, only with different metadata. Is there something else here? I strongly agree that "comments and trackbacks are just entries too..." Given this, I'm puzzled by the various proposals that we need to somehow incorporate recursive feeds or other structural innovations in order to address the "comment problem." To me, a comment is just another entry that happens to have a typed link to the entry which is its subject. It is important, I think, to be careful not to permit too much of our expectations concerning the display of different types of entries into the feed format itself. While some user interfaces may display comments in a fashion structurally different then free-standing entries, it is neither necessary nor wise to allow these structural differences to enter into the feed itself. Doing so will tend to limit the flexibility of the system and opportunities to innovate in the future. For example, if we establish the relationship between entries and comments by doing something like providing for an embedded "comments feed" within a feed document, we may make it difficult to allow cross-feed comments. i.e. Allowing me to create a comment in my feed that refers to an entry or comment in someone else's feed. I think this would be very unfortunate since it is becoming quite apparent that the current mechanisms for commenting are not going to be sustainable long term. The problem with commenting as it is practiced today is that it relies on granting others the right to write into one's blog. Because comments and entries are collocated, in order to create a comment, one must gain write access within the same data administration domain as the entry. This increases the complexity of comment systems greatly -- or results the common approach of granting global write access to comment feeds and relying on post-write moderation of comments. (i.e I get email notifications whenever someone comments on my blog and I then have to inspect the comment to determine if it should be deleted.) The tremendous amount of comment spam that we have is the result of this silliness -- open write access being granted to our comment feeds. Spamming is much less common and much less likely when spammers are forced to maintain their "spam" within their own domains rather then exploiting, like parasites, the domains of others... In the future, I think, we'll see comments being written on the writer's blog which link to the entries or comments upon which they comment. Thus, rather than a comment being identified as such by being an actual insertion into the stream of updates to a feed, we'll see comments being identified by their metadata. Thus, more and more commenting will move to a track-back model (either explicit via mechanisms like trackback or implicit via link tracking tools like PubSub). To summarize: "It's about the Entries, Stupid!" Comments are just entries that refer to other entries as their subjects. Let's not allow the currently anecdotal aspects of commenting implementations to overly influence the mechanisms that we define for supporting commenting. bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 14:27:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23640 for ; Sat, 5 Feb 2005 14:27:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JFdDi045993; Sat, 5 Feb 2005 11:15:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15JFdL3045992; Sat, 5 Feb 2005 11:15:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JFdQi045979 for ; Sat, 5 Feb 2005 11:15:39 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <200502051915340140039699e>; Sat, 5 Feb 2005 19:15:34 +0000 Date: Sat, 5 Feb 2005 12:15:33 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <420514E6.8050201@franklinmint.fm> Message-Id: <4EAA5B5F-77AA-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote: >> Part of our charter is to define a format suitable for archiving >> feeds. > > Right, and breaking the feed format isn't the way to do it. Since > you're advocating versioning, what are your plans for versioning the > state of the feed itself? What if the title changes? It would be > better to archive a series of feed documents. > Okay, I don't imagine you're going to like this, but here's a possibility: 1 Foo Feed ... ... ... 1 Foo Fighter Feed ... ... ... 1 Bar Fight Feed ... ... ... From owner-atom-syntax@mail.imc.org Sat Feb 5 14:32:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23967 for ; Sat, 5 Feb 2005 14:32:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JIXOZ046241; Sat, 5 Feb 2005 11:18:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15JIXwF046239; Sat, 5 Feb 2005 11:18:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JIWYH046233 for ; Sat, 5 Feb 2005 11:18:33 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j15JIRmm007506; Sat, 5 Feb 2005 14:18:28 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNR40839; Sat, 5 Feb 2005 14:18:22 -0500 (EST) Message-Id: <200502051918.CNR40839@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Roger B.'" , "'Henry Story'" Cc: Subject: RE: atom extensibility: Re: Don't mess with HeadInEntry! Date: Sat, 5 Feb 2005 14:18:20 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULnLIOzh+okAsZR9q4FX1Vs5z9LAAGaP4g In-Reply-To: <540e3732050205080611ad4d7e@mail.gmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger Benningfield wrote: > Henry: I suspect that Bob's reaction would have been the same, no > matter how well-defined the extension mechanism. Anything outside > the core will have spotty (at best) support in aggregators and > publishing tools. You are absolutely correct. While I think I feel just as strongly as Henry does that there is a need for a well defined and robust extension mechanism, I also know from past experience that implementation of most extensions is vastly less probable then implementation of core features. My feeling that HeadInEntry or Feeder should be in the Atom core is completely independent of my feelings concerning the utility of and desirability of a robust extension mechanism for Atom. Frankly, I'm a bit miffed by the idea that Henry, or anyone else, could have attempted to "highjack" my concern for what is core and suggest that this implies how I feel about some other mechanism. The cause of extensibility is not enhanced by such underhanded rhetorical trickery. bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 14:56:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25163 for ; Sat, 5 Feb 2005 14:56:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JjNYO047888; Sat, 5 Feb 2005 11:45:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15JjNkf047887; Sat, 5 Feb 2005 11:45:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JjNfG047875 for ; Sat, 5 Feb 2005 11:45:23 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 96730 invoked by uid 17064); 5 Feb 2005 19:45:19 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.2.206]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 5 Feb 2005 19:45:19 -0000 In-Reply-To: <200502051918.CNR40839@ms8.netsolmail.com> References: <200502051918.CNR40839@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9d03ace9088184b2266c01242b2964f2@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Roger B.'" , From: Henry Story Subject: Re: atom extensibility: Re: Don't mess with HeadInEntry! Date: Sat, 5 Feb 2005 20:44:53 +0100 To: X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 5 Feb 2005, at 20:18, Bob Wyman wrote: > Roger Benningfield wrote: >> Henry: I suspect that Bob's reaction would have been the same, no >> matter how well-defined the extension mechanism. Anything outside >> the core will have spotty (at best) support in aggregators and >> publishing tools. > You are absolutely correct. While I think I feel just as strongly as > Henry does that there is a need for a well defined and robust extension > mechanism, I also know from past experience that implementation of most > extensions is vastly less probable then implementation of core > features. Good. > My feeling that HeadInEntry or Feeder should be in the Atom core is > completely independent of my feelings concerning the utility of and > desirability of a robust extension mechanism for Atom. Frankly, I'm a > bit > miffed by the idea that Henry, or anyone else, could have attempted to > "highjack" my concern for what is core and suggest that this implies > how I > feel about some other mechanism. The cause of extensibility is not > enhanced > by such underhanded rhetorical trickery. Yes, but perhaps if everyone's favorite feature were possibly to be left to an extension, then people would be thinking more carefully about getting that very important part right. This is a little like the thought behind Rawl's "Theory of Justice". If you set out to build a good political system, you should try to think of it from the point of view of someone who does not know what position he will have in that society. It helps focus the mind on the plight of the poor. Similarly here, everybody is so concerned to get their bit in the core spec (everyone wants a constitution where thinking they will start of as billionairs) that they don't care to make the extension mechanism clear and well defined. > bob wyman Well to tell the truth I don't understand what the fuss about the head element in the feed is (which is not quite to say that I am fully behind the head_in_entry). I think the head element is just a special entry. Henry Story From owner-atom-syntax@mail.imc.org Sat Feb 5 14:57:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25245 for ; Sat, 5 Feb 2005 14:57:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JjPCJ047902; Sat, 5 Feb 2005 11:45:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15JjPP8047901; Sat, 5 Feb 2005 11:45:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bgo1smout1.broadpark.no (bgo1smout1.broadpark.no [217.13.4.94]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JjO16047856 for ; Sat, 5 Feb 2005 11:45:25 -0800 (PST) (envelope-from asbjorn@tigerstaden.no) Received: from bgo1sminn1.broadpark.no ([217.13.4.93]) by bgo1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IBG006UHEMJII20@bgo1smout1.broadpark.no> for atom-syntax@imc.org; Sat, 05 Feb 2005 20:39:55 +0100 (CET) Received: from quark ([80.202.165.198]) by bgo1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IBG00LQZEZD53E0@bgo1sminn1.broadpark.no> for atom-syntax@imc.org; Sat, 05 Feb 2005 20:47:38 +0100 (CET) Date: Sat, 05 Feb 2005 20:46:42 +0100 From: =?iso-8859-1?Q?Asbj=F8rn_Ulsberg?= Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: <87hdkspad2.fsf@nwalsh.com> To: Norman Walsh Cc: Atom-Syntax Message-id: MIME-version: 1.0 Content-type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <87hdkspad2.fsf@nwalsh.com> User-Agent: Opera M2(BETA1)/8.00 (Win32, build 7401) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Fri, 04 Feb 2005 11:18:17 -0500, Norman Walsh wrote: > I know we're writing an IETF document, but I think there's going to be > a lot of off-the-shelf XML software that understands xsd:dateTimes and > I think it would be a lot better if we defined Date Constructs in > terms of W3C XML Schema Part 2 than RFC 3339. Now I agree as well. -- Asbjørn Ulsberg -=|=- http://virtuelvis.com/quark/ «He's a loathsome offensive brute, yet I can't look away» From owner-atom-syntax@mail.imc.org Sat Feb 5 14:58:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25321 for ; Sat, 5 Feb 2005 14:58:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JpneK048257; Sat, 5 Feb 2005 11:51:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15JpnNR048256; Sat, 5 Feb 2005 11:51:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15JpmYg048248 for ; Sat, 5 Feb 2005 11:51:48 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j15JplVu012348 for ; Sat, 5 Feb 2005 12:51:47 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG000Y1F6BST@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 12:51:47 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG000MSF6A7R@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 12:51:47 -0700 (MST) Date: Sat, 05 Feb 2005 11:51:57 -0800 From: Tim Bray Subject: Re: Entry order In-reply-to: <42051043.6010609@dehora.net> To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Cc: "'Atom Syntax'" Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <158887418.20050201230634@djpowell.net> <200502040425.CNH01907@ms8.netsolmail.com> <1f2ed5cd05020505361047e69d@mail.gmail.com> <60c4bc5a9e87fcc4f4f075fc7084b4ad@sun.com> <8c33b3728daf005e7c6b3540865b82d7@mac.com> <42051043.6010609@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j15JpmYg048249 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Feb 5, 2005, at 10:28 AM, Bill de hÓra wrote: >> You're shockingly small-minded sometimes Tim. > > Rudeness objection. Hey, I'm used to 8 flames before breakfast from Graham compared to which that was a sweet nothing. He hasn't called me "criminally insane" in months and months. I note that in recent months Graham's grownup/childish ratio has been improving markedly, give him a couple years and he'll be fine. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 15:20:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27409 for ; Sat, 5 Feb 2005 15:20:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KA6Yx049649; Sat, 5 Feb 2005 12:10:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15KA6Do049648; Sat, 5 Feb 2005 12:10:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KA4Ju049638 for ; Sat, 5 Feb 2005 12:10:04 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j15KA4Vu022205 for ; Sat, 5 Feb 2005 13:10:04 -0700 (MST) Received: from fe8 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBG0011AG0RGK@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sat, 05 Feb 2005 13:10:04 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBG000GMG0Q87@mail.sun.net> for atom-syntax@imc.org; Sat, 05 Feb 2005 13:10:02 -0700 (MST) Date: Sat, 05 Feb 2005 12:10:13 -0800 From: Tim Bray Subject: Re: xsd:dateTime vs. RFC 3339 In-reply-to: To: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= Cc: Norman Walsh , Atom-Syntax Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=ISO-8859-1; format=flowed References: <87hdkspad2.fsf@nwalsh.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j15KA5Ju049640 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote: >> I know we're writing an IETF document, but I think there's going to be >> a lot of off-the-shelf XML software that understands xsd:dateTimes and >> I think it would be a lot better if we defined Date Constructs in >> terms of W3C XML Schema Part 2 than RFC 3339. > > Now I agree as well. I tend to agree as well; in this case, the fact that this is an XML vocabulary is probably more relevant than the fact that it's an IETF RFC. So can we please have a Pace to call out to XSD? I'm pretty sure that implementors would just use the libraries and The Right Thing Would Happen. -Tim From owner-atom-syntax@mail.imc.org Sat Feb 5 15:32:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28281 for ; Sat, 5 Feb 2005 15:32:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KMqI3050593; Sat, 5 Feb 2005 12:22:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15KMqFM050592; Sat, 5 Feb 2005 12:22:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KMpT1050578 for ; Sat, 5 Feb 2005 12:22:51 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id A9F9699B2; Sat, 5 Feb 2005 14:18:22 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14342-08; Sat, 5 Feb 2005 14:18:20 -0600 (CST) Received: from boblaptop (unknown [10.255.205.41]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sat, 5 Feb 2005 14:18:20 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceRepeatIdInDocument posted Date: Sat, 5 Feb 2005 15:22:37 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULq/4Ua08tElsLRsmUCFNQ0BBbTAADGrKw In-Reply-To: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> Message-Id: <20050205201822.A9F9699B2@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > A number of people in the working group have expressed a desire to > be able to archive the revision history of an entry--not just the > latest version--which is a fairly natural thing to want to do with > an archive format. That's not something any RSS version has > attempted as far as I'm aware. This is something that we actually do at PubSub for internal purposes. Basically, we produce very large "log files" which are, effectively, Atom files. These files contain a concatenation of all the updated entries that we've discovered -- in the sequence we discovered them. Each of the entries has a element (our temporary equivalent of HeadInEntry or Feeder) so that we can map an entry back to the feed that it came from and have a permanent record of the feed metadata at the time we found the entry. The atom:id's of entries in these files are the ones with which they were published or atom:ids that we created to cover for entries that were published without atom:ids. A single file can contain multiple instances of entries that share the same atom:id. What we have is very large atom feed documents that contain all discovered states of entries and, in the case where an entry appears in multiple source feeds, all copies of all entries from all feeds. This is an effective and simple archival format. Undoubtedly, we could do all sorts of things to make a more robust format -- but the degree of benefit received for the additional cost is not immediately and apparently compelling. As long as multiple instances/versions of an entry are permitted to exist in a single atom document while sharing the same atom:id, the current Atom document format provides a useable "archive format." The only real issue we have with this system is the fact that although the Atom specification requires that atom:ids be globally unique there is no defined mechanism or convention to ensure such uniqueness. Thus, we are forced to assume that atom:ids are at best unique within the context of a single source-feed. The *real* unique identifier for an entry thus becomes +. This means that we can't do cross-feed duplicate detection based soley on atom:id. To do cross-feed duplicate detection we have to rely on textual analysis, a variety of heuristics, and other bits of guesswork. However, this is not a problem specific to "archiving." It is a problem with the definition of atom:id and will impact any atom processor that attempts to meld content from multiple feeds into a single view. This problem is very unfortunate when you realize that Entry Documents aren't always associated with Feeds... Thus, one must fabricate a "feed" context for the atom:ids found in Entry documents if you want to mix feed-independent Entry Documents with Entries that come from feeds. (Note: Most existing "news aggregators" don't concern themselves with these issues since they typically present feed-oriented rather than entry-oriented views of data and existing news aggregators have yet to deal with the issue of Entry Documents that exist outside feeds. Because of their feed orientation, existing news aggregators violate the principle of "It's about the Entries, Stupid!" Hopefully, this will change.) bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 15:47:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28793 for ; Sat, 5 Feb 2005 15:47:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KcMbk052306; Sat, 5 Feb 2005 12:38:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15KcMEN052305; Sat, 5 Feb 2005 12:38:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KcMrp052197 for ; Sat, 5 Feb 2005 12:38:22 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id C5CC699D8; Sat, 5 Feb 2005 14:34:00 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14472-05; Sat, 5 Feb 2005 14:33:59 -0600 (CST) Received: from boblaptop (unknown [10.255.205.41]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sat, 5 Feb 2005 14:33:59 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Danny Ayers'" , Cc: "'David Powell'" , "'Atom Syntax'" Subject: RE: Entry order Date: Sat, 5 Feb 2005 15:38:17 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULh7cU65gYOYCwQUWl4QCiMU29WQAOV+Mg In-Reply-To: <1f2ed5cd05020505361047e69d@mail.gmail.com> Message-Id: <20050205203400.C5CC699D8@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Danny Ayers wrote: > The killer problem of using doc order is that the feed data *will* > be aggregated and republished. Precisely! As the blogosphere grows and as the number of feeds grow, I feel it is inevitable that we are simply going to have to give up the current "feed-oriented" focus and concentrate more on the entries. Ie: "It's about the Entries, Stupid!". We're seeing the same pattern in "blogs" that we saw with web sites. In the old days, you maintained a list of known web sites and scanned them on a regular basis. This was augmented by surfing (i.e. "manual RDF..."). However, today, there is simply too much information and too many sites for us all to rely on "favorites" lists and bookmarks. Thus, Google has become the tool for navigating between sites. What we look for today is not "sites" but rather "pages." While today, the blogosphere is largely focused on the discussion of "blogs" and "feeds", I feel that in the future, we'll see a growing focus on entries... Web site designers have, in many cases, already begun to learn the new design disciplines that focus on a page in isolation instead of the "site-oriented" disciplines that were popular in the 90's and relied on carefully planned navigation paths through a site. Today's web designer must recognize that "deep pages" are accessed directly -- not by navigating a path from the "home page." Similarly, while today's feed developers think they can rely on presenting an entry within the context of other entries -- which relies on their entire feed being experienced or read, in the future, feed developers will come to realize that it is NOT their feeds that are read by people, rather it is the entries that get read. Thus, any relationship between entries must be contained within the entry -- it can't rely on position within feed or other contextual clues that require entry-external data. As Danny says: "Far better to declare the information in the data (like the date) and let the client (or intermediary) sort according to the user's requirements." To allow document order to be significant compromises the utility of aggregation and search mechanisms. This should not be tolerated. bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 15:54:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29094 for ; Sat, 5 Feb 2005 15:54:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KhqFN052961; Sat, 5 Feb 2005 12:43:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Khqm8052960; Sat, 5 Feb 2005 12:43:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15Khpig052939 for ; Sat, 5 Feb 2005 12:43:51 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 Feb 2005 20:43:36 -0000 Received: from pD9FF0486.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.134) by mail.gmx.net (mp014) with SMTP; 05 Feb 2005 21:43:36 +0100 X-Authenticated: #1915285 Message-ID: <42052FE3.8050400@gmx.de> Date: Sat, 05 Feb 2005 21:43:15 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tim Bray CC: =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Norman Walsh , Atom-Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Tim Bray wrote: > > On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote: > >>> I know we're writing an IETF document, but I think there's going to be >>> a lot of off-the-shelf XML software that understands xsd:dateTimes and >>> I think it would be a lot better if we defined Date Constructs in >>> terms of W3C XML Schema Part 2 than RFC 3339. >> >> >> Now I agree as well. > > > I tend to agree as well; in this case, the fact that this is an XML > vocabulary is probably more relevant than the fact that it's an IETF > RFC. So can we please have a Pace to call out to XSD? I'm pretty sure > that implementors would just use the libraries and The Right Thing Would > Happen. -Tim Risking that I sound like a broken report...: xsd:dateTime allows a superset of what we can represent in RFC3339 (I'm talking about semantics, not syntax here). So if we *don't* profile it, the spec will need to explain how to obtain an ordering from a set of atom:updated timestamps where some are lacking the timezone information. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Feb 5 15:54:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29125 for ; Sat, 5 Feb 2005 15:54:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KhfBf052948; Sat, 5 Feb 2005 12:43:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Khfbt052947; Sat, 5 Feb 2005 12:43:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf14.cluster1.charter.net (mxsf14.cluster1.charter.net [209.225.28.214]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Kheth052936 for ; Sat, 5 Feb 2005 12:43:41 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip12.cluster1.charter.net (mxip12a.cluster1.charter.net [209.225.28.142]) by mxsf14.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j15KhWel021520 for ; Sat, 5 Feb 2005 15:43:32 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip12.cluster1.charter.net with ESMTP; 05 Feb 2005 15:43:31 -0500 X-Ironport-AV: i="3.88,180,1102309200"; d="scan'208"; a="774783299:sNHT15488724" Received: from ndw by localhost with local (Exim 4.44) id 1CxWlj-0003Mp-Rl for atom-syntax@imc.org; Sat, 05 Feb 2005 15:43:05 -0500 To: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Sat, 05 Feb 2005 15:43:03 -0500 In-Reply-To: (Tim Bray's message of "Sat, 05 Feb 2005 12:10:13 -0800") Message-ID: <87brayviug.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable / Tim Bray was heard to say: | I tend to agree as well; in this case, the fact that this is an XML | vocabulary is probably more relevant than the fact that it's an IETF | RFC. So can we please have a Pace to call out to XSD? I'm pretty Done. PaceDatesXSD Be seeing you, norm =2D-=20 Norman Walsh | Man's great misfortune is that he has http://nwalsh.com/ | no organ, no kind of eyelid or brake, | to mask or block a thought, or all | thought, when he wants to.--Paul Val=C3=A9ry --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCBS/XOyltUcwYWjsRArfuAJ9bunlO0KZ+uSkVnbpd84cy+0wl9wCcCYYw XOMNMG/KFV+m8W+Gd23fEc8= =hV9K -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Sat Feb 5 16:01:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29545 for ; Sat, 5 Feb 2005 16:01:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Kqdro053511; Sat, 5 Feb 2005 12:52:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Kqdrf053510; Sat, 5 Feb 2005 12:52:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15KqbYX053498 for ; Sat, 5 Feb 2005 12:52:38 -0800 (PST) (envelope-from derhoermi@gmx.net) Received: (qmail invoked by alias); 05 Feb 2005 20:52:32 -0000 Received: from dsl-082-082-078-179.arcor-ip.net (EHLO helix) (82.82.78.179) by mail.gmx.net (mp009) with SMTP; 05 Feb 2005 21:52:32 +0100 X-Authenticated: #723575 From: Bjoern Hoehrmann To: Tim Bray Cc: atom-syntax@imc.org Subject: Re: xsd:dateTime vs. RFC 3339 Date: Sat, 05 Feb 2005 21:52:34 +0100 Message-ID: <42053035.198084328@smtp.bjoern.hoehrmann.de> References: <87hdkspad2.fsf@nwalsh.com> In-Reply-To: X-Mailer: Forte Agent 1.92/32.572 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Tim Bray wrote: >I tend to agree as well; in this case, the fact that this is an XML >vocabulary is probably more relevant than the fact that it's an IETF >RFC. So can we please have a Pace to call out to XSD? I'm pretty sure >that implementors would just use the libraries and The Right Thing >Would Happen. -Tim That depends on whether we include restrictions that such libraries would ignore... -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de 68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ From owner-atom-syntax@mail.imc.org Sat Feb 5 16:02:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29566 for ; Sat, 5 Feb 2005 16:02:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KnbrF053304; Sat, 5 Feb 2005 12:49:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Knb46053303; Sat, 5 Feb 2005 12:49:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KnMvt053286 for ; Sat, 5 Feb 2005 12:49:37 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 0FB7899D8; Sat, 5 Feb 2005 14:45:04 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14543-07; Sat, 5 Feb 2005 14:45:03 -0600 (CST) Received: from boblaptop (unknown [10.255.205.41]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sat, 5 Feb 2005 14:45:03 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Graham'" , "'Tim Bray'" Cc: "'Atom Syntax'" Subject: RE: Entry order Date: Sat, 5 Feb 2005 15:49:20 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULpVAF19Kpn+oVTvSqBHQMRFYIzwAHaS0g In-Reply-To: <8c33b3728daf005e7c6b3540865b82d7@mac.com> Message-Id: <20050205204504.0FB7899D8@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > You're shockingly small-minded sometimes Tim. Do we really need to have this stuff in this forum? The Macintouch and BBC News feeds that you provide as examples simply demonstrate that there is a need for some mechanism to specify order relationships between entries. The mere fact that in older versions of syndication formats, document order was the only available mechanism for hinting at these relationships should not be a compelling reason to avoid defining more useful and robust order-specification mechanisms. Order relationships between entries should be specified *within* entries, not implied or derived from the context within which those entries are found. "It's about the Entries, Stupid!" bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 16:06:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29873 for ; Sat, 5 Feb 2005 16:06:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KtD4Q053838; Sat, 5 Feb 2005 12:55:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15KtDOV053837; Sat, 5 Feb 2005 12:55:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15KtCsE053829 for ; Sat, 5 Feb 2005 12:55:13 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxWxE-0004iA-Qg; Sat, 05 Feb 2005 20:54:56 +0000 Message-ID: <4205329F.1050009@franklinmint.fm> Date: Sat, 05 Feb 2005 15:54:55 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Tim Bray , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Norman Walsh , Atom-Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <42052FE3.8050400@gmx.de> In-Reply-To: <42052FE3.8050400@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Risking that I sound like a broken report...: xsd:dateTime allows a > superset of what we can represent in RFC3339 (I'm talking about > semantics, not syntax here). So if we *don't* profile it, the spec will > need to explain how to obtain an ordering from a set of atom:updated > timestamps where some are lacking the timezone information. > I would tend to agree. Can we have that regex go in the Pace itself? That would make the proposal pretty much editorial, since the set of allowed timestamps would be the same (right?). Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 16:15:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00324 for ; Sat, 5 Feb 2005 16:15:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15L7n8P054803; Sat, 5 Feb 2005 13:07:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15L7nDR054802; Sat, 5 Feb 2005 13:07:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15L7mhw054795 for ; Sat, 5 Feb 2005 13:07:48 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxX9c-00053e-Ki; Sat, 05 Feb 2005 21:07:44 +0000 Message-ID: <4205359F.3060506@franklinmint.fm> Date: Sat, 05 Feb 2005 16:07:43 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <4EAA5B5F-77AA-11D9-9564-003065EA6144@geckotribe.com> In-Reply-To: <4EAA5B5F-77AA-11D9-9564-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote: > >>> Part of our charter is to define a format suitable for archiving feeds. >> >> >> Right, and breaking the feed format isn't the way to do it. Since >> you're advocating versioning, what are your plans for versioning the >> state of the feed itself? What if the title changes? It would be >> better to archive a series of feed documents. >> > Okay, I don't imagine you're going to like this, but here's a possibility: > > > > ... You're right! I think it's vile :). It would be reasonable to want a title for the root. Perhaps the location of an HTML version would be good to know as well... oops. How about this. A series of feeds is probably overkill... I'd just use subversion. So, let's take a look at what Bob said: Bob Wyman wrote: > As long as multiple instances/versions of an entry are permitted to > exist in a single atom document while sharing the same atom:id, the current > Atom document format provides a useable "archive format." This is clearly a non-starter for a syndication format, since ignoramus apps that don't keep a history will show more entries in a feed than ones that do. hmm... Also, there's mnot's suggestion that there should be an archiving "profile". I don't really like all the baggage with profiles and mustUnderstand and all that. Why don't we just define an element called that acts exactly like except for the id restriction. This approach also happens to be "mustUnderstand". Could you live with that? Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 16:16:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00385 for ; Sat, 5 Feb 2005 16:16:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15L7amR054777; Sat, 5 Feb 2005 13:07:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15L7aq1054776; Sat, 5 Feb 2005 13:07:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j15L7YFn054762 for ; Sat, 5 Feb 2005 13:07:35 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 05 Feb 2005 21:07:28 -0000 Received: from pD9FF0486.dip.t-dialin.net (EHLO [192.168.0.2]) (217.255.4.134) by mail.gmx.net (mp028) with SMTP; 05 Feb 2005 22:07:28 +0100 X-Authenticated: #1915285 Message-ID: <42053576.3090500@gmx.de> Date: Sat, 05 Feb 2005 22:07:02 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mint@franklinmint.fm CC: Tim Bray , =?ISO-8859-1?Q?Asbj=F8rn_Ulsberg?= , Norman Walsh , Atom-Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <42052FE3.8050400@gmx.de> <4205329F.1050009@franklinmint.fm> In-Reply-To: <4205329F.1050009@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > I would tend to agree. Can we have that regex go in the Pace itself? > That would make the proposal pretty much editorial, since the set of > allowed timestamps would be the same (right?). As long as the set of allowed timestamps and their semantics is the same, that's fine with me. I still have doubts why this is better than sticking with the RFC version, though :-) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Sat Feb 5 16:28:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00888 for ; Sat, 5 Feb 2005 16:28:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LK3NN055784; Sat, 5 Feb 2005 13:20:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15LK3ef055783; Sat, 5 Feb 2005 13:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf28.cluster1.charter.net (mxsf28.cluster1.charter.net [209.225.28.228]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LK2bS055766 for ; Sat, 5 Feb 2005 13:20:03 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip02.cluster1.charter.net (mxip02a.cluster1.charter.net [209.225.28.132]) by mxsf28.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j15LJumG002704 for ; Sat, 5 Feb 2005 16:19:56 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip02.cluster1.charter.net with ESMTP; 05 Feb 2005 16:19:56 -0500 X-Ironport-AV: i="3.88,180,1102309200"; d="scan'208"; a="589877392:sNHT14581760" Received: from ndw by localhost with local (Exim 4.44) id 1CxXKv-0003dM-UU for atom-syntax@imc.org; Sat, 05 Feb 2005 16:19:25 -0500 To: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <42052FE3.8050400@gmx.de> <4205329F.1050009@franklinmint.fm> From: Norman Walsh X-URL: http://nwalsh.com/ Date: Sat, 05 Feb 2005 16:19:20 -0500 In-Reply-To: <4205329F.1050009@franklinmint.fm> (Robert Sayre's message of "Sat, 05 Feb 2005 15:54:55 -0500") Message-ID: <876516vh5z.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Robert Sayre was heard to say: | I would tend to agree. Can we have that regex go in the Pace itself? The regex is in the pace. Be seeing you, norm =2D-=20 Norman Walsh | Life is a great bundle of little http://nwalsh.com/ | things.--Oliver Wendell Holmes --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCBThYOyltUcwYWjsRAoDiAJ0X3Of0VlHlZNZeGif1uUgE/DKbZgCffDPI zuKAHFjMLcIPhbGk6RmTtmU= =9Rxw -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Sat Feb 5 16:47:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02023 for ; Sat, 5 Feb 2005 16:47:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15Lb0CT056890; Sat, 5 Feb 2005 13:37:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15Lb04T056889; Sat, 5 Feb 2005 13:37:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LaxrG056882 for ; Sat, 5 Feb 2005 13:36:59 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxXbr-0005IG-Ln; Sat, 05 Feb 2005 21:36:55 +0000 Message-ID: <42053C76.7080805@franklinmint.fm> Date: Sat, 05 Feb 2005 16:36:54 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: xsd:dateTime vs. RFC 3339 References: <87hdkspad2.fsf@nwalsh.com> <42052FE3.8050400@gmx.de> <4205329F.1050009@franklinmint.fm> <876516vh5z.fsf@nwalsh.com> In-Reply-To: <876516vh5z.fsf@nwalsh.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Robert Sayre was heard to say: > | I would tend to agree. Can we have that regex go in the Pace itself? > > The regex is in the pace. > I took the liberty of adding it to the proposal section. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 16:51:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02404 for ; Sat, 5 Feb 2005 16:51:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LfUnq057162; Sat, 5 Feb 2005 13:41:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15LfUQh057161; Sat, 5 Feb 2005 13:41:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m6f195e42.tmodns.net [66.94.25.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LfTHE057148 for ; Sat, 5 Feb 2005 13:41:30 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 3E2BC99B2; Sat, 5 Feb 2005 15:37:02 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14891-04; Sat, 5 Feb 2005 15:37:01 -0600 (CST) Received: from boblaptop (unknown [10.255.205.41]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sat, 5 Feb 2005 15:37:01 -0600 (CST) Reply-To: From: "Bob Wyman" To: , "'Antone Roundy'" Cc: Subject: RE: PaceRepeatIdInDocument posted Date: Sat, 5 Feb 2005 16:41:18 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcULyHvmf8XMW66lSCu61Li1uOdkewAAabHg In-Reply-To: <4205359F.3060506@franklinmint.fm> Message-Id: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: >> Bob Wyman wrote: >> As long as multiple instances/versions of an entry are permitted to >> exist in a single atom document while sharing the same atom:id, the >> current Atom document format provides a useable "archive format." > This is clearly a non-starter for a syndication format, since ignoramus > apps that don't keep a history will show more entries in a feed than ones >that do. hmm... So what? "Ignoramus apps" will do all sorts of things that don't make sense. Why in the world would we define a new "" document type simply because part of the world's population is of non-optimal intelligence? If "ignoramus apps" display too many entries, users will either shun them or pester their developers with demands that they fix the bugs. The marketplace has many mechanisms to address this and similar problems. We don't need to write spec text to address this issue. If anything we should address the lack of a standard method for creating atom:id's and we should create a requirement that atom:updated must be changed on *every* update -- not just on the whim of the entry author... It is all this informality and hand-waving around atom:id and atom:updated that is the source of any trouble with using atom:feed as an archive format. Given globally unique ids (atom:id) and version tags (atom:updated) for entries, archiving would be trivial even for "ignoramus apps". bob wyman From owner-atom-syntax@mail.imc.org Sat Feb 5 16:53:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA02586 for ; Sat, 5 Feb 2005 16:53:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LjZY9057415; Sat, 5 Feb 2005 13:45:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15LjZxt057414; Sat, 5 Feb 2005 13:45:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15LjY32057407 for ; Sat, 5 Feb 2005 13:45:34 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxXk9-0005OY-G3; Sat, 05 Feb 2005 21:45:29 +0000 Message-ID: <42053E78.5060800@franklinmint.fm> Date: Sat, 05 Feb 2005 16:45:28 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> In-Reply-To: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Robert Sayre wrote: > >>>Bob Wyman wrote: >>> As long as multiple instances/versions of an entry are permitted to >>>exist in a single atom document while sharing the same atom:id, the >>>current Atom document format provides a useable "archive format." >> >>This is clearly a non-starter for a syndication format, since ignoramus >>apps that don't keep a history will show more entries in a feed than ones >>that do. hmm... > > So what? "Ignoramus apps" will do all sorts of things that don't > make sense. Why in the world would we define a new "" document type > simply because part of the world's population is of non-optimal > intelligence? If "ignoramus apps" display too many entries, users will > either shun them or pester their developers with demands that they fix the > bugs. The marketplace has many mechanisms to address this and similar > problems. We don't need to write spec text to address this issue. If > anything we should address the lack of a standard method for creating > atom:id's and we should create a requirement that atom:updated must be > changed on *every* update -- not just on the whim of the entry author... Oh yes, let's rehash the date and id discussions. > It is all this informality and hand-waving around atom:id and > atom:updated that is the source of any trouble with using atom:feed as an > archive format. Given globally unique ids (atom:id) and version tags > (atom:updated) for entries, archiving would be trivial even for "ignoramus > apps". Sorry, Bob. You're not arguing with me. You're arguing against every other syndication format that does identifiers. I don't particularly care if we change it, we'll just look incredibly foolish and impractical. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 17:24:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04497 for ; Sat, 5 Feb 2005 17:24:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MCUc9059582; Sat, 5 Feb 2005 14:12:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15MCUOE059581; Sat, 5 Feb 2005 14:12:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MCSMq059574 for ; Sat, 5 Feb 2005 14:12:29 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxYAB-0005Y9-NI; Sat, 05 Feb 2005 22:12:23 +0000 Message-ID: <420544C5.3020304@franklinmint.fm> Date: Sat, 05 Feb 2005 17:12:21 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> In-Reply-To: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > It is all this informality and hand-waving around atom:id and > atom:updated that is the source of any trouble with using atom:feed as an > archive format. Given globally unique ids (atom:id) and version tags > (atom:updated) for entries, archiving would be trivial even for "ignoramus > apps". > BTW, if it weren't for the atrocious design error of banning recursive feeds, we wouldn't even be having this argument. A feed would always mean "current status", while a series of them would mean "stream". Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 17:51:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06327 for ; Sat, 5 Feb 2005 17:51:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MdZOm061982; Sat, 5 Feb 2005 14:39:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15MdZO4061981; Sat, 5 Feb 2005 14:39:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MdUes061967 for ; Sat, 5 Feb 2005 14:39:34 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j15MdQCi010725 for ; Sat, 5 Feb 2005 17:39:28 -0500 (EST) Message-ID: <42054AFD.8010204@intertwingly.net> Date: Sat, 05 Feb 2005 17:38:53 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339) References: <87hdkspad2.fsf@nwalsh.com> <87brayviug.fsf@nwalsh.com> In-Reply-To: <87brayviug.fsf@nwalsh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Tim Bray was heard to say: > | I tend to agree as well; in this case, the fact that this is an XML > | vocabulary is probably more relevant than the fact that it's an IETF > | RFC. So can we please have a Pace to call out to XSD? I'm pretty > > Done. PaceDatesXSD -1 See http://www.imc.org/atom-syntax/mail-archive/msg06611.html (Note: Scott is the IETF Director responsible for advising our workgroup) Having written the datetime support for Apache Axis (a webservice implementation based on XSD schema and having hosted a number of SOAP interop facilities, I am +1 on the regular expression limitation, believe that all dates that that conform to this limitation are valid RFC 3339 and xsd:dateTime values, and believe that it will interop with all of the existing XSD implementations. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Feb 5 18:09:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09182 for ; Sat, 5 Feb 2005 18:09:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MuUPn063320; Sat, 5 Feb 2005 14:56:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15MuUiM063319; Sat, 5 Feb 2005 14:56:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15MuTfp063313 for ; Sat, 5 Feb 2005 14:56:29 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j15MuRCi025577 for ; Sat, 5 Feb 2005 17:56:27 -0500 (EST) Message-ID: <42054EF9.5040207@intertwingly.net> Date: Sat, 05 Feb 2005 17:55:53 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <24D16A20-779D-11D9-9564-003065EA6144@geckotribe.com> <420514E6.8050201@franklinmint.fm> In-Reply-To: <420514E6.8050201@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > Antone Roundy wrote: > >> Neither of these is equivalent to atom:id--according to this text, the >> {item_uri} and rdf:about for a particular item could change each time >> you transmit the feed. Whether we accept this Pace or not, that is >> not what is intend for atom:id. Could you explain how these are in >> any way relevant to this Pace? > > I'm sorry, that's nonsense. We don't get to make up how syndication > works. I understand the thinking behind your proposal, but it *doesn't > work*. > >> Part of our charter is to define a format suitable for archiving feeds. > > Right, and breaking the feed format isn't the way to do it. Since you're > advocating versioning, what are your plans for versioning the state of > the feed itself? What if the title changes? It would be better to > archive a series of feed documents. -1 to the Pace. Like Robert, I believe that this Pace breaks the feed format. Here is a *recent* example of somebody who associated the same id (in this case rdf:about) with different entries: http://sourceforge.net/mailarchive/message.php?msg_id=10636557 I would prefer a solution whereby if somebody wants to include versions of entries into a feed they need to include a version specific identifier. Or that we define a third type of Atom document in section 2, namely an atom:archive. - Sam Ruby From owner-atom-syntax@mail.imc.org Sat Feb 5 19:00:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13150 for ; Sat, 5 Feb 2005 19:00:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15NnXgM069232; Sat, 5 Feb 2005 15:49:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15NnXNB069231; Sat, 5 Feb 2005 15:49:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15NnXSF069217 for ; Sat, 5 Feb 2005 15:49:33 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j15Nmokl010637 for ; Sat, 5 Feb 2005 23:48:50 GMT Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: <957d7963cd94b91146eb98f51941519e@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: Atom Syntax From: Graham Subject: PaceClarifyDateUpdated Date: Sat, 5 Feb 2005 23:48:51 +0000 X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit #pragma section-numbers off == Abstract == Clarify when not to update atom:updated == Status == Open == Rationale == The second sentence ("not all modifications...") is a bit vague and conceivably contradicts the first (which implies "only some", second implies "most"). NB This is not an attempt to change the meaning. == Proposal == Change second sentence of: The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the producer considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value. To: Therefore, other modifications SHOULD NOT result in a changed atom:updated value. == Impacts == None. == Notes == ---- CategoryProposals From owner-atom-syntax@mail.imc.org Sat Feb 5 19:01:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13194 for ; Sat, 5 Feb 2005 19:01:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15NsCKf069608; Sat, 5 Feb 2005 15:54:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j15NsClb069607; Sat, 5 Feb 2005 15:54:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j15NsBm5069585 for ; Sat, 5 Feb 2005 15:54:11 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1157473wra for ; Sat, 05 Feb 2005 15:54:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:content-type:content-transfer-encoding; b=SMTxgbHoKnoH8+XOu9O1mliwf02A8lB2LfskgcvzjOEEPSpmDcgeIJzWJ2H06q3fYvhwzQXoyiC1Nn15KrlthmjSd7jk88R0iJwmtKd0GmB7WqfxGTcZzl0/W3QImQ/F5vIjJ+03maz+DldzQ29nKEWiRG0J7Klw7CojBkkp16g= Received: by 10.54.57.30 with SMTP id f30mr31080wra; Sat, 05 Feb 2005 15:54:03 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 43sm221056wri.2005.02.05.15.54.03; Sat, 05 Feb 2005 15:54:03 -0800 (PST) Message-ID: <42055C97.1090803@gmail.com> Date: Sat, 05 Feb 2005 15:53:59 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: New: PaceProfileAttribute Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is a modified version of Mark Nottingham's initial idea that reflects my thinking on the subject as developed through the mailing list discussion. I posted it as PaceProfileAttribute as opposed to Mark's initial PaceProfile in case he wanted to go ahead and attempt to submit his original idea under the PaceProfile name. == Abstract == Replacement for @version that places an optional @profile attribute on atom:feed and atom:entry elements. @profile identifies a list of Profiles against which the feed/entry element was generated. A profile is a specification detailing which metadata elements are required in the entry/feed and the cardinality of such. A Core Profile is defined to which all Feed/Entry elements are assumed to adhere to unless otherwise specified using the @profile attribute. This proposal rearranges the current spec a bit by moving the metadata containment requirements for both the feed and entry elements into a new section of the document. == Status == Proposed. == Rationale == (Taken from Mark Nottingham's initial proposed posted to the mailing list) "There are a number of use cases for Atom (e.g., blogs, news, archiving, stock quotes, systems monitoring); each has potentially different requirements for the presences of certain kinds of metadata. To cater to these use cases, and allow implementations to make assumptions about feed content when presenting it, we need to identify the *profile* of metadata that a feed can be expected to contain." "Furthermore, we need to ship at least one profile with the spec. Right now, it's embedded in the schema of what metadata elements are required; it would be better to explicitly call it out." This proposal is an extension of Mark's initial concept that allows the profile attribute to be a list of profile names. The idea is that a single entry/feed may be created to adhere to multiple profiles. For example, a given feed may conform to blog, news and archiving profiles. An important aspect of this proposal is that it places no behavioral requirements on the part of Atom implementations. The profiles attribute is strictly informational. If a atom processor finds a feed that uses a profile it does not understand, it can ignore that profile and attempt to parse the feed under the assumption that it adheres to the Core Profile that would be defined by the spec. == Proposal == * replace the @version attribute on the atom:feed element with a @profile attribute on both the atom:feed and atom:entry elements 4.1.1 The "profile" Attribute atom:feed and atom:entry elements MAY have a "profile" attribute whose value is a list of names or URI's identifying one or more metadata profiles that have been applied to the feed or entry. A profile is a description what metadata elements are required and optionally, for each one that is required, the maximum number that may be present. Each item in the list MUST be either a name, which is non-empty and does not contain any colon (":") or space (" ") characters, or a URI [RFC3986]. The use of relative references is not allowed. If a name is given, implementations MUST consider the name to be equivalent to the same name registered within the IANA Registry of Atom Profiles Section 9, and thus the URI that would be obtained by appending the value of the name to the string "http://www.iana.org/assignments/atom/profiles". The value of "profile" helps consumers process the entry/feed by identifying which metadata elements are required in the item. That said, the identification of profiles is intended to be informational only and does not impose any behavioral requirements on implementations. The profile name "core" is used to identify the Atom Core Profile described in Section 6.1. An entry or feed element that does not specify a "profile" attribute MUST adhere to the Core Profile. An entry or feed element that adheres to multiple profiles SHOULD specify each applied profile in the "profile" attribute. 6.0 Atom Profiles Atom Profiles are specifications that identify named collections of metadata elements that are required to be present in either the feed or entry elements. Each profile is identified either by a name registered within the IANA Registry of Atom Profiles described in Section 9.2 or a URI. A profile describes the the elements that MUST be present within the entry or feed element and the maximum/minimum number of such elements that are allowed. The profile(s) to which an entry or feed element applies is identified using a @profile attribute on either entry or feed elements. Profiles are informational only, and do not impose any behavioral requirements on implementations. Specifically, the only Profile that Atom implementations are required to support is the Atom Core Profile described in Section 6.1 below. Support for all other profiles is optional. If an implementation is presented with a feed or entry whose @profile attribute specifies a profile unknown to the implementation, the implementation MAY choose to ignore that profile and continue processing. 6.1 The Atom Core Profile The Atom Core Profile is the default profile for all Atom feeds and entries and is identified by the name "core" as registered in the IANA Registry of Atom Profiles. All entry and feed elements that do not explicitly specify a @profile attribute MUST conform to the Atom Core Profile. 6.1.1 Requirements for atom:feed atom:feed elements conforming to the Atom Core Profile MUST adhere to the following requirements. * atom:feed elements MUST contain exactly one atom:title element * atom:feed elements MUST contain at least one atom:link element with a rel attribute value of "alternate" * atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. If a feed's atom:link element with type="alternate" resolves to an HTML document, then that document SHOULD have a autodiscovery link element [Atom-autodiscovery] that reflects back to the feed. atom:head elements MAY contain additional atom:link elements beyond those described above. * 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. atom:head elements MUST NOT contain more than one atom:author element. [[inheritance]] * atom:feed elements MUST NOT contain more than one an atom:contributor element. * atom:feed elements MUST NOT contain more than one an atom:copyright element. * atom:feed elements MUST NOT contain more than one an atom:id element. * atom:feed elements MUST contain exactly one atom:updated element. * atom:feed elements MAY contain any number of atom:category elements. * atom:feed elements MUST NOT contain more than one atom:post element. * atom:feed elements MUST NOT contain more than one atom:introspection element. * atom:feed elements MUST NOT contain more than one atom:tagline element. * atom:feed elements MUST NOT contain more than one atom:generator element. * atom:feed elements MUST NOT contain more than one atom:info element. * atom:feed elements MAY contain any number of atom:enty elements. 6.1.2 Requirements for atom:entry * atom:entry elements MUST have exactly one "atom:title" element. * atom:entry elements MUST contain exactly one atom:id element. * atom:entry elements that contain no child atom:content element MUST contain at least one atom:link element with a rel attribute value of "alternate". atom:entry elements MUST NOT contain more than one atom:link element with a rel attribute value of "alternate" that has the same type attribute value. atom:entry elements MAY contain additional atom:link elements beyond those described above. * atom:entry elements MUST contain exactly one atom:updated element. * atom:entry elements MUST NOT contain more than one atom:published element. * atom:entry elements MUST contain exactly one atom:author element, unless, in an Atom Feed Document, the atom:feed element contains an atom:author element itself. atom:entry elements MUST NOT contain more than one atom:author element. * atom:entry elements MUST NOT contain more than one atom:contributor element. * atom:entry elements MUST NOT contain more than one atom:host element. * atom:entry elements MUST NOT contain more than one atom:copyright element. * atom:entry elements MAY contain any number of atom:category elements. * atom:entry elements MUST contain an atom:summary element in any of the following cases: * the atom:entry element contains no atom:content element. * the atom:entry contains an atom:content which has a "src" attribute (and is thus empty). * the atom:entry contains content which is encoded in Base64; i.e. the "type" attribute of atom:content is a MIME media type [RFC2045] and does not begin with "text/" nor end with "+xml". * atom:entry elements MUST NOT contain more than one atom:summary element. * atom:entry elements MUST NOT contain more than one atom:edit element. 6.2 Interoperability Considerations for Atom Profiles Interoperability between Atom implementations relies on the ability to for those implementations to rely on a consistent collection of required metadata elements. The Core Profile described above is intended to provide a foundation upon which such interoperability may be based. New Atom Profiles MAY choose to either extend or modify the requirements specified by the Core. Profiles that seek only to extend the Core without changing any of those core requirements will have a much greater chance of ensuring appropriate levels of interoperability. Profiles that modify the core requirements run the risk of breaking interoperability in Atom implementations. Because of this, for the sake of protecting interoperability, it is highly recommended that new profiles seek to extend the core rather than modify it. 9.2 Registry of Atom Profiles This registry is maintained by IANA and initially contains the Atom Core Profile identified by the name "core". New assignments are subject to IESG Approval, as outlined in [?]. Requests should be made by email to IANA, which will then forward the request to the IESG requesting approval. The request should contain discussion of at least the following five topics: * A value for the name identifying the profile that conforms to the syntax rule given in Section 4.1.1 * Common name for the profile type * Description of the profile requirements / semantics including how the profile modifies/extends the Atom Core Profile * Atom Core Profile interoperability considerations * Security considerations == Impacts == * Replaces @version * Requires some reorganization of the spec. Specifically, the pieces that define which metadata elements must be included in both the feed and entry elements would be moved to the section that defines the Atom Core Profile. * Allows other profiles to the developed that may or may not be compatible with the core. For interoperability sake, strongly recommends that new profiles that happened to be developed be created so that they are compatible with the core. * Requires the creation of a IANA Registry for Atom Profiles that operates in similar fashion to the registry of link relations. == Notes == This was initially proposed by Mark Nottingham and developed further through discussion on the mailing list. ---- CategoryProposals -- - James M Snell From owner-atom-syntax@mail.imc.org Sat Feb 5 19:51:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17499 for ; Sat, 5 Feb 2005 19:51:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j160hE4O073483; Sat, 5 Feb 2005 16:43:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j160hEme073482; Sat, 5 Feb 2005 16:43:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j160hDFn073470 for ; Sat, 5 Feb 2005 16:43:14 -0800 (PST) (envelope-from sah@428cobrajet.net) Received: from A31P ([68.100.55.187]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050206004308.ZCBD29855.lakermmtao08.cox.net@A31P>; Sat, 5 Feb 2005 19:43:08 -0500 From: "Scott Hollenbeck" To: "'Sam Ruby'" , "'Atom Syntax'" Subject: RE: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339) Date: Sat, 5 Feb 2005 19:43:04 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42054AFD.8010204@intertwingly.net> Thread-Index: AcUL081I4dWYGt59Sauxu/OF8z5aDAAD/M+Q X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Message-Id: <20050206004308.ZCBD29855.lakermmtao08.cox.net@A31P> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Having written the datetime support for Apache Axis (a > webservice implementation based on XSD schema and having > hosted a number of SOAP interop facilities, I am +1 on the > regular expression limitation, believe that all dates that > that conform to this limitation are valid RFC 3339 and > xsd:dateTime values, and believe that it will interop with > all of the existing XSD implementations. I'm not sure that I understand why some folks seem to think that this has to be an either-or situation. As Sam noted, it's quite possible to specify date-time syntax that conform to both RFC 3339 and XML Schema Part 2. Here's what I did in RFC 3731: 2.4. Dates and Times Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form using upper case "T" and "Z" characters defined in [RFC3339] MUST be used to represent date-time values as XML Schema does not support truncated date-time forms or lower case "T" and "Z" characters. I then used the xsd:dateTime data type in my schema (with an appropriate reference to Part 2), and all is well. The normative text eliminates some of the 3339 possibilities that don't work or play well with XML Schema. -Scott- From owner-atom-syntax@mail.imc.org Sat Feb 5 20:14:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19046 for ; Sat, 5 Feb 2005 20:14:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1616NnC076291; Sat, 5 Feb 2005 17:06:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1616NF5076290; Sat, 5 Feb 2005 17:06:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j1616MjO076270 for ; Sat, 5 Feb 2005 17:06:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 32827 messnum 2832089 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 01:06:16 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail06.svc.cra.dublin.eircom.net (qp 32827) with SMTP; 6 Feb 2005 01:06:16 -0000 Message-ID: <42056D83.1030002@dehora.net> Date: Sun, 06 Feb 2005 01:06:11 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceClarifyDateUpdated References: <957d7963cd94b91146eb98f51941519e@mac.com> In-Reply-To: <957d7963cd94b91146eb98f51941519e@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > #pragma section-numbers off > > == Abstract == > > Clarify when not to update atom:updated +1 cheers Bill From owner-atom-syntax@mail.imc.org Sat Feb 5 20:31:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19930 for ; Sat, 5 Feb 2005 20:31:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161K5N6077342; Sat, 5 Feb 2005 17:20:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j161K5SU077341; Sat, 5 Feb 2005 17:20:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161K5qU077329 for ; Sat, 5 Feb 2005 17:20:05 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020601200001300k5tmde>; Sun, 6 Feb 2005 01:20:00 +0000 Date: Sat, 5 Feb 2005 18:19:58 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42054EF9.5040207@intertwingly.net> Message-Id: <37486608-77DD-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 03:55 PM, Sam Ruby wrote: > -1 to the Pace. Just to be sure we don't forget, if we don't want to allow multiple versions of an entry in the same feed document, we need to add language to the spec to clarify that point. > Like Robert, I believe that this Pace breaks the feed format. Here is > a *recent* example of somebody who associated the same id (in this > case rdf:about) with different entries: > > http://sourceforge.net/mailarchive/message.php?msg_id=10636557 Without the Pace, the feed wouldn't validate...and who knows exactly how applications would handle the entries in question. With it, the feed would validate, but the entries in question would be handled incorrectly since they'd be considered the same entry. Either way, buggy feeds are bad. > I would prefer a solution whereby if somebody wants to include > versions of entries into a feed they need to include a version > specific identifier. Or that we define a third type of Atom document > in section 2, namely an atom:archive. Of the two, I'd strongly prefer an archive document type. Requiring a version specific-identifier and another identifier or method to tie all the versions together seems unnecessarily complex. From owner-atom-syntax@mail.imc.org Sat Feb 5 20:32:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19974 for ; Sat, 5 Feb 2005 20:32:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161Q6jI077828; Sat, 5 Feb 2005 17:26:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j161Q6qt077827; Sat, 5 Feb 2005 17:26:06 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161Q55I077816 for ; Sat, 5 Feb 2005 17:26:05 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020601255901200g7asse>; Sun, 6 Feb 2005 01:25:59 +0000 Date: Sat, 5 Feb 2005 18:25:57 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4205359F.3060506@franklinmint.fm> Message-Id: <0D8F591B-77DE-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 02:07 PM, Robert Sayre wrote: > Antone Roundy wrote: >> On Saturday, February 5, 2005, at 11:48 AM, Robert Sayre wrote: >>>> Part of our charter is to define a format suitable for archiving >>>> feeds. >>> >>> >>> Right, and breaking the feed format isn't the way to do it. Since >>> you're advocating versioning, what are your plans for versioning the >>> state of the feed itself? What if the title changes? It would be >>> better to archive a series of feed documents. >>> >> Okay, I don't imagine you're going to like this, but here's a >> possibility: >> >> >> ... > > You're right! I think it's vile :). It would be reasonable to want a > title for the root. Perhaps the location of an HTML version would be > good to know as well... oops. I left that out of the example, but sure ( has a in PaceAggregationDocument): Archive of feed XYZ ... ... > How about this. A series of feeds is probably overkill... I'd just use > subversion. So, let's take a look at what Bob said: > > Bob Wyman wrote: >> As long as multiple instances/versions of an entry are permitted to >> exist in a single atom document while sharing the same atom:id, the >> current >> Atom document format provides a useable "archive format." > > This is clearly a non-starter for a syndication format, since > ignoramus apps that don't keep a history will show more entries in a > feed than ones that do. hmm... > > Also, there's mnot's suggestion that there should be an archiving > "profile". I don't really like all the baggage with profiles and > mustUnderstand and all that. Why don't we just define an element > called that acts exactly like except for the id > restriction. This approach also happens to be "mustUnderstand". Could > you live with that? > This would not address your question of tracking changes to the feed's metadata. I'd be perfectly happy with not allowing atom:id to be repeated in a or the hypothetical if we had an element which acts exactly like except that atom:id may be repeated. From owner-atom-syntax@mail.imc.org Sat Feb 5 20:49:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21633 for ; Sat, 5 Feb 2005 20:49:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161fbBN079946; Sat, 5 Feb 2005 17:41:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j161fbch079945; Sat, 5 Feb 2005 17:41:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161fbBP079935 for ; Sat, 5 Feb 2005 17:41:37 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020601413101300k9bo8e>; Sun, 6 Feb 2005 01:41:32 +0000 Date: Sat, 5 Feb 2005 18:41:30 -0700 Subject: Re: PaceRepeatIdInDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <0D8F591B-77DE-11D9-9564-003065EA6144@geckotribe.com> Message-Id: <3997CA7A-77E0-11D9-9564-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, February 5, 2005, at 06:25 PM, Antone Roundy wrote: > I'd be perfectly happy with not allowing atom:id to be repeated in a > or the hypothetical if we had an > element which acts exactly like except that atom:id may > be repeated. > Oops, correction: I'd be perfectly happy with not allowing atom:id to be repeated in an Atom Feed Document or the hypothetical Atom Aggregation Document if we had an Atom Archive Document type (with an element as its document element) which acts exactly like an Atom Aggregation Document, except that the atom:ids of the s and s in it could be repeated. I wouldn't particularly care whether an Atom Archive Document were allowed to archive multiple feeds, or whether it were limited to archiving a single feed (ie., all of it's s would be required to have the same ). From owner-atom-syntax@mail.imc.org Sat Feb 5 20:59:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22160 for ; Sat, 5 Feb 2005 20:59:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161o2LS080726; Sat, 5 Feb 2005 17:50:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j161o22M080725; Sat, 5 Feb 2005 17:50:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j161o1dx080717 for ; Sat, 5 Feb 2005 17:50:02 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.23]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxbYl-0007QY-FR; Sun, 06 Feb 2005 01:49:59 +0000 Message-ID: <420577C3.8020301@franklinmint.fm> Date: Sat, 05 Feb 2005 20:49:55 -0500 From: Robert Sayre Reply-To: mint@franklinmint.fm User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument posted References: <0D8F591B-77DE-11D9-9564-003065EA6144@geckotribe.com> In-Reply-To: <0D8F591B-77DE-11D9-9564-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: >> > This would not address your question of tracking changes to the feed's > metadata. I'd be perfectly happy with not allowing atom:id to be > repeated in a or the hypothetical if we had an > element which acts exactly like except that > atom:id may be repeated. Nah, overkill. If there's an element like atom:head or atom:source-feed in atom:entry, the only changes that would be missed are changes to the number of entries in the feed. If you want an element that acts just like a feed, but isn't one so there can be no recursion, I think it's a gross hack. So, perhaps atom:archive shouldn't define anything besides atom:entry. Robert Sayre From owner-atom-syntax@mail.imc.org Sat Feb 5 21:10:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22728 for ; Sat, 5 Feb 2005 21:10:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1621lm4081819; Sat, 5 Feb 2005 18:01:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1621lli081818; Sat, 5 Feb 2005 18:01:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1621l0F081806 for ; Sat, 5 Feb 2005 18:01:47 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050206020140.PRGP19250.fed1rmmtao04.cox.net@[192.168.0.100]>; Sat, 5 Feb 2005 21:01:40 -0500 In-Reply-To: References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Sat, 5 Feb 2005 18:01:41 -0800 To: Mark Nottingham X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: > What does that mean? SOAP is a "Must Ignore format," but it also has a > way of saying that you have to understand a particular extension; as I > said before, this is one of the big problems with HTTP. mustUnderstand > should be used sparingly, but sometimes it's necessary. The problem with that statement (about HTTP) is that absence of a must-understand in HTTP is not one of its big problems. Yes, I know lots of people have talked about it as a limiting factor in the syntax of HTTP, but to call it an actual problem would say that it prevented some good from being accomplished. Henrik spent an enormous amount of time devising a "must understand" feature for HTTP, only to find that the features needing it were either not worth deploying in the first place or too risky to deploy even on a "must understand" basis. The features that people actually needed to deploy were able to be standardized because those people were willing to work hard to come to a common agreement on the benefit of the feature. One problem is that the "must understand" feature is intended to prevent dumb software from performing an action when it doesn't know how to do it right. In reality, software tends to have bugs and developers tend to be optimistic, and thus there is no way to guarantee the software is going to do it right even if it claims to know how. In the end, we just waste a bunch of cycles on unimplemented features and failed requests. Another problem is that the features that benefit from a must-understand bit tend to be socially reprehensible (and thus the only way they could be deployed is via artificial demand). As soon as one of those features get deployed, the hackers come out and turn off the "must understand" bit for that feature, defeating the protocol in favor of their own view of what is right on the Internet. Things that a syndication format might want to make mandatory are copyright controls and micropayments, but both have been shown in practice to require either a willingness on the part of the recipient to accept that specific restriction (i.e., human intervention and understanding) or forceful requirement by the sender (i.e., encryption). In both cases, agreements have to be established with the user in advance, before they even receive the content, and thus do not need a "must understand" feature. In fact, "must understand" has no value in a network-based application except as positive guidance for intermediaries, which is something that can still be accomplished under mustIgnore with a bit of old-fashioned advocacy. ....Roy From owner-atom-syntax@mail.imc.org Sat Feb 5 22:22:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27138 for ; Sat, 5 Feb 2005 22:22:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j163Awxc088590; Sat, 5 Feb 2005 19:10:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j163AwJS088589; Sat, 5 Feb 2005 19:10:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j163Av4M088552 for ; Sat, 5 Feb 2005 19:10:57 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 16:11:10 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 14:10:23 +1100 Subject: Re: Call for final Paces for consideration: deadline imminent From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j163Aw4M088584 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 6/2/05 4:27 AM, "David Powell" wrote: > Although we could keep the model we have (let's call it the 'mutable entries' > model), it isn’t clear on a number of issues. Eg, if an old version of an > entry has some property that isn’t present in a newer version, does that > property still apply to the new instance? The answer is presumably 'no' but > it isn't obvious from the spec. Under a 'multiple instances' model, it would > be implicit. +1 now go write a pace, and quickly e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:02:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29176 for ; Sat, 5 Feb 2005 23:02:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j163sTm1092948; Sat, 5 Feb 2005 19:54:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j163sTBR092947; Sat, 5 Feb 2005 19:54:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j163sS7R092940 for ; Sat, 5 Feb 2005 19:54:29 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 16:55:13 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 14:54:26 +1100 Subject: Re: PaceRepeatIdInDocument posted From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050205213702.3E2BC99B2@mailrelay.t-mobile.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/2/05 8:41 AM, "Bob Wyman" wrote: > If > anything we should address the lack of a standard method for creating > atom:id's and we should create a requirement that atom:updated must be > changed on *every* update -- not just on the whim of the entry author... arrgh! atom:updated was proposed and accepted because it provided the noise-reduction feature of "author whim". atom:modified was shouted down because (I suspect) people were sick of discussing dates, and because it was argued that if two entries though technically different in some content/metadata was not "significantly" different enough in the publishers opinion then it was acceptable that the newer version could be safely dropped on the floor. At the time I argued that we need both, and that without atom:modified that atom:updated would get polluted with every nitpicky modification under the sun, thus destroying the original motivation for an date over a date. And now you are proposing to enshrine that pollution into the spec. Like I said: arrgh! If you want atom:modified, you need to write a pace, and you need to really bolster the rationale with all the use cases that require it, and be prepared for a lot of resistance based not on the logic of the element, but instead on a false logic of it having been discussed before (completely ignoring any new and presumably stronger rationale in the pace). Religion is like that. e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:07:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29422 for ; Sat, 5 Feb 2005 23:07:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1641Hjk093612; Sat, 5 Feb 2005 20:01:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1641Hho093611; Sat, 5 Feb 2005 20:01:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1641G6H093602 for ; Sat, 5 Feb 2005 20:01:16 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 17:02:01 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 15:01:15 +1100 Subject: Re: PaceDatesXSD (was: xsd:dateTime vs. RFC 3339) From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42054AFD.8010204@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/2/05 9:38 AM, "Sam Ruby" wrote: > I am +1 on the regular expression limitation, > believe that all dates that that conform to this limitation are valid > RFC 3339 and xsd:dateTime values, and believe that it will interop with > all of the existing XSD implementations. where "this" is the regex? that regex allows this totally bogus value 2005-13-34T25:65:96+00:65 there are test cases in the validator to check this, but those test cases will no longer be supported by the spec and will thus be a bug in the validator :-( e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:12:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29695 for ; Sat, 5 Feb 2005 23:12:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1645CkA094034; Sat, 5 Feb 2005 20:05:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1645Ce4094033; Sat, 5 Feb 2005 20:05:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1645A9c094025 for ; Sat, 5 Feb 2005 20:05:11 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 17:05:56 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 15:05:10 +1100 Subject: Re: PaceRepeatIdInDocument posted From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42054EF9.5040207@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/2/05 9:55 AM, "Sam Ruby" wrote: > I would prefer a solution whereby if somebody wants to include versions > of entries into a feed they need to include a version specific > identifier. +1. e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:12:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA29706 for ; Sat, 5 Feb 2005 23:12:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1646Nbr094174; Sat, 5 Feb 2005 20:06:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1646NHU094173; Sat, 5 Feb 2005 20:06:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1646L3Y094155 for ; Sat, 5 Feb 2005 20:06:22 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 17:07:07 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 15:06:21 +1100 Subject: Re: PaceClarifyDateUpdated From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <957d7963cd94b91146eb98f51941519e@mac.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/2/05 10:48 AM, "Graham" wrote: > Therefore, other modifications SHOULD NOT result in a changed > atom:updated value. +1 e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:21:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00058 for ; Sat, 5 Feb 2005 23:21:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j164BqP6094539; Sat, 5 Feb 2005 20:11:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j164BqNx094538; Sat, 5 Feb 2005 20:11:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j164BoJR094530 for ; Sat, 5 Feb 2005 20:11:51 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 17:12:35 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 15:11:49 +1100 Subject: Re: New: PaceProfileAttribute From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <42055C97.1090803@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/2/05 10:53 AM, "James M Snell" wrote: > atom:feed and atom:entry elements MAY have a "profile" attribute whose > value is a list of names or URI's identifying one or more metadata > profiles that have been applied to the feed or entry. A profile is a > description what metadata elements are required and optionally, for each > one that is required, the maximum number that may be present. > > Each item in the list MUST be either a name, which is non-empty and does > not contain any colon (":") or space (" ") characters, or a URI > [RFC3986]. The use of relative references is not allowed. If a name is > given, implementations MUST consider the name to be equivalent to the > same name registered within the IANA Registry of Atom Profiles Section > 9, and thus the URI that would be obtained by appending the value of the > name to the string "http://www.iana.org/assignments/atom/profiles". suggestion: s/a list/a space delimited list/ otherwise this might be legal (but ambiguously parseable): profile="feed:archive:http://www.example.com/" also, might we need to make clear that the URI must not be a relative uri? e. From owner-atom-syntax@mail.imc.org Sat Feb 5 23:33:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00608 for ; Sat, 5 Feb 2005 23:33:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j164Ngth095279; Sat, 5 Feb 2005 20:23:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j164NgE2095278; Sat, 5 Feb 2005 20:23:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j164NfxW095266 for ; Sat, 5 Feb 2005 20:23:42 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j164N7UW016389; Sun, 6 Feb 2005 04:23:12 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2f3a1b72623bc4988d3b166416d16fe5@mac.com> Content-Transfer-Encoding: 7bit Cc: "'Atom Syntax'" From: Graham Subject: Re: PaceRepeatIdInDocument posted Date: Sun, 6 Feb 2005 04:23:06 +0000 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 Feb 2005, at 4:17 am, Eric Scheid wrote: > On 6/2/05 3:28 AM, "Graham" wrote: > >>> 1. In order to show the revision history of a particular entry, >>> multiple revisions of the entry must be able to appear in the same >>> document. >> >> But "must" we have this facility? > > your other options are: > > * we must rule out the possibility > * we must leave it ambiguous > > your choice would be? "rule out the possibility", at least in syndication feeds. Graham From owner-atom-syntax@mail.imc.org Sun Feb 6 00:31:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04243 for ; Sun, 6 Feb 2005 00:31:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j165LRPs099761; Sat, 5 Feb 2005 21:21:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j165LRDW099760; Sat, 5 Feb 2005 21:21:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j165LPGi099750 for ; Sat, 5 Feb 2005 21:21:26 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Sun, 6 Feb 2005 18:22:11 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 06 Feb 2005 16:21:25 +1100 Subject: dereferencability of ? From: Eric Scheid To: Atom Syntax Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit consider assume for the moment that is a valid scheme is that kind of URI something we want to allow in link/@href? putting it another way, look closely at this example [...] http://example.com/892379587493 [...] http://example.com/892379587494 [...] The key distinction being that the URI in question is referencing an URI, and not the dereferenceable location URI. e. From owner-atom-syntax@mail.imc.org Sun Feb 6 00:44:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04751 for ; Sun, 6 Feb 2005 00:44:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j165XmFX000790; Sat, 5 Feb 2005 21:33:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j165XmHN000789; Sat, 5 Feb 2005 21:33:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j165XmjA000771 for ; Sat, 5 Feb 2005 21:33:48 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020605334201200fvutde>; Sun, 6 Feb 2005 05:33:42 +0000 Date: Sat, 5 Feb 2005 22:33:41 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceArchiveDocument posted From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I'd rather have held off while we discussed further, but as the deadline is approaching, here it is. Abstract Creates a new option for the document element, , which can contain multiple feeds or instances of the same feed, in order to archive the states of a feed or feeds and the states of the entries published while the feed was in each of those states. Specifies that multiple instances of a resource with the same atom:id is illegal in Feed Documents, Entry Documents, and if PaceAggregationDocument2 as adopted, Aggregation Documents, but is legal in Archive Documents. Rationale 1. Our charter speaks of creating an archive format. 2. If we wish to be able to archive multiple revisions of an entry or the contents of a feed's head in a single document, we must either specify that the atom:id of a resource be repeatable within a document intended as an archive, or that we invent some other method of identifying multiple instances of the same entry or feed metadata. Multiple instances within an archive type document would be simpler. 3. Multiple versions of an entry or feed in a non-archive document is unprecedented in syndication formats. In spite of the fact that changing feed metadata after an entry is published breaks the connection between the state of the feed metadata at the time of publishing the entry and the entry, this is how feeds have always worked, so no exception to the one-feed-instance-per-document rule need be made for Aggregation Documents--that is a special case reserved only for archiving. See http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more. From owner-atom-syntax@mail.imc.org Sun Feb 6 01:12:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06549 for ; Sun, 6 Feb 2005 01:12:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1663Q10003960; Sat, 5 Feb 2005 22:03:26 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1663QTQ003959; Sat, 5 Feb 2005 22:03:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1663Pgf003920 for ; Sat, 5 Feb 2005 22:03:26 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1191639wra for ; Sat, 05 Feb 2005 22:03:20 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=DR0Ppqk986icmAYOILjyWwGEwoGDcogtvVVqkFIFNxzqZTZiRQkH2ee1n8+6NYwtrHYfeedYQq8dje1YhDRc4jhBWcLhE86XsLgljPpOiVY2ZnnFcjGUWPZj+wxTh62C6eAn5XT6lZXWmnGu8ywUKqDbiTfueLvWCchMzDlITm8= Received: by 10.54.48.33 with SMTP id v33mr191206wrv; Sat, 05 Feb 2005 22:03:20 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 34sm43701wra.2005.02.05.22.03.20; Sat, 05 Feb 2005 22:03:20 -0800 (PST) Message-ID: <4205B322.1080507@gmail.com> Date: Sat, 05 Feb 2005 22:03:14 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hmm.. I'm sorry but this just seems wierd to me. ... id:version1 id:version2 id:version3 What is the point of having the feed elements in there at all? If entries are indeed able to stand on their own, why not just go ahead and get rid of the containing feed element altogether? I mean, it is the entries that are being archived, not the feeds that just happened to contain them at some moment in time right? ... id:version1 id:version2 id:version3 I guess I just don't see the point of archiving the feed. - James M Snell Antone Roundy wrote: > > I'd rather have held off while we discussed further, but as the deadline > is approaching, here it is. > > Abstract > > Creates a new option for the document element, , which can > contain multiple feeds or instances of the same feed, in order to > archive the states of a feed or feeds and the states of the entries > published while the feed was in each of those states. Specifies that > multiple instances of a resource with the same atom:id is illegal in > Feed Documents, Entry Documents, and if PaceAggregationDocument2 as > adopted, Aggregation Documents, but is legal in Archive Documents. > > Rationale > > 1. Our charter speaks of creating an archive format. > 2. If we wish to be able to archive multiple revisions of an entry or > the contents of a feed's head in a single document, we must either > specify that the atom:id of a resource be repeatable within a document > intended as an archive, or that we invent some other method of > identifying multiple instances of the same entry or feed metadata. > Multiple instances within an archive type document would be simpler. > 3. Multiple versions of an entry or feed in a non-archive document > is unprecedented in syndication formats. In spite of the fact that > changing feed metadata after an entry is published breaks the connection > between the state of the feed metadata at the time of publishing the > entry and the entry, this is how feeds have always worked, so no > exception to the one-feed-instance-per-document rule need be made for > Aggregation Documents--that is a special case reserved only for archiving. > > See http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more. > > From owner-atom-syntax@mail.imc.org Sun Feb 6 01:23:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07060 for ; Sun, 6 Feb 2005 01:23:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j166G6IP008975; Sat, 5 Feb 2005 22:16:06 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j166G5Qd008974; Sat, 5 Feb 2005 22:16:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j166G5bL008933 for ; Sat, 5 Feb 2005 22:16:05 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1259517wri for ; Sat, 05 Feb 2005 22:15:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=ObsYY2VFp5LU5gL4IQ1Cf0dr9x18cF37QmrJo3NlkGjkP88VjWs40T3kpOGc/KMEx1/7t6kzlrhVEvj38CrtPPvg8oF/xIFmmVfgyIzDfZhpRpAgmRznNt885KkWs7AA/37TEg8jez52sopJf39hH7WrFV5kxiHyOkEmsTaQmdA= Received: by 10.54.50.3 with SMTP id x3mr104173wrx; Sat, 05 Feb 2005 22:15:59 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 65sm316944wra.2005.02.05.22.15.59; Sat, 05 Feb 2005 22:15:59 -0800 (PST) Message-ID: <4205B618.3090603@gmail.com> Date: Sat, 05 Feb 2005 22:15:52 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My challenge with the idea of mustUnderstand in Atom is in trying to figure out how the heck it would realistically be used for anything worthwhile. Take blog content for instance, if my blog reader accesses a feed that contains an entry with a mustUnderstand metadata element that my reader does not understand, does that mean my reader is not allowed to show me that content? If so, that's kinda stupid when I can open the same feed in a browser and view the angle bracket version without any problem. In SOAP, mustUnderstand makes sense given that the messages passed around are generally intended for automated consumption designed to kick of or affect processes in some way. Atom feeds are not typically going to be used that way. There may be some of that going on, but nothing that would warrant any intense need to have mustUnderstand built into the Atom core. If anything, it could be moved off into an extension and implemented only by those few who may actually need it. - James M Snell Roy T. Fielding wrote: > > On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: > >> What does that mean? SOAP is a "Must Ignore format," but it also has a >> way of saying that you have to understand a particular extension; as I >> said before, this is one of the big problems with HTTP. mustUnderstand >> should be used sparingly, but sometimes it's necessary. > ... > > In fact, "must understand" has no value in a network-based > application except as positive guidance for intermediaries, > which is something that can still be accomplished > under mustIgnore with a bit of old-fashioned advocacy. > > ....Roy > > From owner-atom-syntax@mail.imc.org Sun Feb 6 02:08:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18029 for ; Sun, 6 Feb 2005 02:08:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1670PO2030251; Sat, 5 Feb 2005 23:00:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1670PhV030249; Sat, 5 Feb 2005 23:00:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1670OuG030237 for ; Sat, 5 Feb 2005 23:00:24 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j1670NTh029400; Sun, 6 Feb 2005 02:00:23 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id CNY83294; Sun, 6 Feb 2005 02:00:22 -0500 (EST) Message-Id: <200502060700.CNY83294@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceArchiveDocument posted Date: Sun, 6 Feb 2005 02:00:20 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMD6tsOaftOe3vTqS6CT1xMyb8uQACZbIg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -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 From owner-atom-syntax@mail.imc.org Sun Feb 6 02:26:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29609 for ; Sun, 6 Feb 2005 02:26:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j167FSNL035719; Sat, 5 Feb 2005 23:15:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j167FS42035718; Sat, 5 Feb 2005 23:15:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j167FRBm035610 for ; Sat, 5 Feb 2005 23:15:28 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52575 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228725AbVBFHPL (ORCPT ); Sun, 6 Feb 2005 09:15:11 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <957d7963cd94b91146eb98f51941519e@mac.com> References: <957d7963cd94b91146eb98f51941519e@mac.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: PaceClarifyDateUpdated Date: Sun, 6 Feb 2005 09:15:10 +0200 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 6, 2005, at 01:48, Graham wrote: > Change second sentence of: > > The "atom:updated" element is a Date construct indicating the most > recent instant in time when an entry or feed was modified in a way > the producer considers significant. Therefore, not all > modifications > necessarily result in a changed atom:updated value. > > To: > > Therefore, other modifications SHOULD NOT result in a changed > atom:updated value. What do you propose one should do when the current system to which Atom output is to be added do not record such updates but only records the date when the bytes changed? The modification dates in my current RSS feed are based on the HTTP Last-Modified value returned by Apache. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Sun Feb 6 03:20:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02435 for ; Sun, 6 Feb 2005 03:20:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1688dKI055574; Sun, 6 Feb 2005 00:08:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1688dkw055573; Sun, 6 Feb 2005 00:08:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1688cEc055508 for ; Sun, 6 Feb 2005 00:08:38 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 56277 invoked by uid 17064); 6 Feb 2005 08:08:28 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.8.44]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Feb 2005 08:08:28 -0000 In-Reply-To: <200502060700.CNY83294@ms8.netsolmail.com> References: <200502060700.CNY83294@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: "'Antone Roundy'" , From: Henry Story Subject: Re: PaceArchiveDocument posted Date: Sun, 6 Feb 2005 09:08:04 +0100 To: X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 agree. Very serious -1 for me. I think the versioning element of id works very well. I am using it in my BlogEd model currently. I think the feed works very well as an archiving format already. No need to change anything that works well. Furthermore I think one should prove that harm is being done by the id as version feature (which would be difficult to show, because I have implemented this, Bob has implemented it, and neither of us have come across a problem). Henry > bob wyman > From owner-atom-syntax@mail.imc.org Sun Feb 6 05:09:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09086 for ; Sun, 6 Feb 2005 05:09:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j169uuXB092275; Sun, 6 Feb 2005 01:56:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j169uu3c092274; Sun, 6 Feb 2005 01:56:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j169utG2092253 for ; Sun, 6 Feb 2005 01:56:55 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1279565wri for ; Sun, 06 Feb 2005 01:56:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=gisvD88qKI/lZGK+noskFT1yh29FQdmpK6vxGzCmkPgab0Y/9XvxcIo1sg7hd2a6zp74cAysy3m7SXFC+t37voAQeVNHh0m/XTdYYlNTNk2v38BZd3rZiomK1SL9/jOUcZi1wbpKYZQm0u6ZFt0sHs4Kr12h8jml7ahtAKdrc+0= Received: by 10.54.18.63 with SMTP id 63mr114248wrr; Sun, 06 Feb 2005 01:56:45 -0800 (PST) Received: by 10.54.18.2 with HTTP; Sun, 6 Feb 2005 01:56:45 -0800 (PST) Message-ID: <540e3732050206015616d5a93f@mail.gmail.com> Date: Sun, 6 Feb 2005 03:56:45 -0600 From: "Roger B." Reply-To: "Roger B." To: Henri Sivonen Subject: Re: PaceClarifyDateUpdated Cc: Atom Syntax In-Reply-To: <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <957d7963cd94b91146eb98f51941519e@mac.com> <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > What do you propose one should do when the current system to which Atom > output is to be added do not record such updates but only records the > date when the bytes changed? Henri: As a practical matter? If that's what you have, that's what you use. But a lot of it comes down to knowing your audience and your priorities. If something on your box routinely tweaks your Last-Modified dates without making material changes, and you've got a lot of readers using aggregators that flag updated entries, you'll probably annoy some folks. You get to decide if that matters to you... if it does, turn off whatever is changing Last-Modified, or kludge together something to insert static dates into atom:updated. -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Sun Feb 6 05:22:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09831 for ; Sun, 6 Feb 2005 05:22:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16ADqLL097612; Sun, 6 Feb 2005 02:13:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16ADq8V097610; Sun, 6 Feb 2005 02:13:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16ADobE097565 for ; Sun, 6 Feb 2005 02:13:50 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so804447wri for ; Sun, 06 Feb 2005 02:13:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=Tblc59Hu5QupX2QGvelCIydES1ln6dDHzzCEybUetN+wq/ynZCeZCI4WmmOjwZ6XIe9VurWRdrS1MPZ4Ot15DkAxPwD/Y9iZmoX7mOY6IMbrE4XbTSjd43gOpbld1jXUrRllT3RDytCvp45booy3bF9o8GoPqbhuIyafFPsnYMg= Received: by 10.54.32.67 with SMTP id f67mr164107wrf; Sun, 06 Feb 2005 02:13:43 -0800 (PST) Received: by 10.54.18.2 with HTTP; Sun, 6 Feb 2005 02:13:43 -0800 (PST) Message-ID: <540e373205020602137943c113@mail.gmail.com> Date: Sun, 6 Feb 2005 04:13:43 -0600 From: "Roger B." Reply-To: "Roger B." To: bob@wyman.us Subject: Re: Open Comments..... Cc: atom-syntax@imc.org In-Reply-To: <200502051909.CNR36538@ms8.netsolmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <1f2ed5cd05020502293ca3984b@mail.gmail.com> <200502051909.CNR36538@ms8.netsolmail.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > The problem with commenting as it is practiced today is that it > relies on granting others the right to write into one's blog. > ... > Thus, more and more commenting will move to a > track-back model (either explicit via mechanisms like > trackback or implicit > via link tracking tools like PubSub). Bob: Bah, bug, and hum. Comments are just micro-message boards, and message boards have been getting along just fine for many, many years without the help of PubSub or any other third party. More importantly, a reply that exists within the context of the source and a reply that exists in another space entirely are very different things... they're written differently, perceived differently, and often aim for different goals. That's not a problem to be solved. With that said, I don't think Atom needs to bake in anything fancy for comments. Personally, I'd be quite content if Joe tapped out a wfw:commentAtom and called it a day. -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Sun Feb 6 06:18:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13041 for ; Sun, 6 Feb 2005 06:18:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16B83kn016639; Sun, 6 Feb 2005 03:08:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16B83ZY016638; Sun, 6 Feb 2005 03:08:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16B82si016535 for ; Sun, 6 Feb 2005 03:08:02 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-12.adsl-net.finnetcom.net ([217.140.228.12]:52924 "EHLO [217.140.228.12]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228809AbVBFLHo (ORCPT ); Sun, 6 Feb 2005 13:07:44 +0200 In-Reply-To: <540e3732050206015616d5a93f@mail.gmail.com> References: <957d7963cd94b91146eb98f51941519e@mac.com> <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> <540e3732050206015616d5a93f@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <34b8342e11d8093498d6697ea717bfed@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henri Sivonen Subject: Re: PaceClarifyDateUpdated Date: Sun, 6 Feb 2005 13:07:42 +0200 To: "Roger B." X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 6, 2005, at 11:56, Roger B. wrote: >> What do you propose one should do when the current system to which >> Atom >> output is to be added do not record such updates but only records the >> date when the bytes changed? > > Henri: As a practical matter? Yes. Also as a spec expectation--that is, how often is the "SHOULD NOT" expected to be violated. Will the SHOULD NOT be violated so often that it dilutes the meaning of all SHOULD NOTs? > If that's what you have, that's what you use. Right. The alternatives would be making significant changes to the system or not producing an Atom feed. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Sun Feb 6 06:27:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13370 for ; Sun, 6 Feb 2005 06:27:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16BGFCa019394; Sun, 6 Feb 2005 03:16:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16BGFYd019393; Sun, 6 Feb 2005 03:16:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16BGFbv019385 for ; Sun, 6 Feb 2005 03:16:15 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 71745 invoked by uid 17064); 6 Feb 2005 11:16:15 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.137.179]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Feb 2005 11:16:15 -0000 In-Reply-To: <42056D83.1030002@dehora.net> References: <957d7963cd94b91146eb98f51941519e@mac.com> <42056D83.1030002@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Atom Syntax From: Henry Story Subject: Re: PaceClarifyDateUpdated Date: Sun, 6 Feb 2005 12:16:10 +0100 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j16BGFbv019386 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thinking about it, I would be in favor of clarifying it to be "any change should result in a date update". Clients can do simple diffs and work out themselves if the changes warrant a new date. Presumably clients that see that the only change has been to the white space layout may decide that this is not important enough to notify their user. Henry On 6 Feb 2005, at 02:06, Bill de hÓra wrote: > Graham wrote: >> #pragma section-numbers off >> == Abstract == >> Clarify when not to update atom:updated > > +1 > > cheers > Bill > From owner-atom-syntax@mail.imc.org Sun Feb 6 07:08:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16240 for ; Sun, 6 Feb 2005 07:08:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16Bwgjw033807; Sun, 6 Feb 2005 03:58:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16Bwgg7033806; Sun, 6 Feb 2005 03:58:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16BwgoS033798 for ; Sun, 6 Feb 2005 03:58:42 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 9153 invoked by uid 17064); 6 Feb 2005 11:58:41 -0000 Received: from unknown (HELO [192.168.0.5]) ([83.112.137.179]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Feb 2005 11:58:41 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <259a507076bcb16747d00cc2caf4d664@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: PaceClarifyDateUpdated Date: Sun, 6 Feb 2005 12:58:36 +0100 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From what has been said recently previous versions of RSS had no versioning mechanism. It was therefore not possible for software to automate the difference tracking behavior. Hence your problem is partly related to the limitations in the previous formats. Since Atom does in fact have a versioning feature, it should be very easy for software to allow the user to select the sensitivity to changes that he desires to be made aware of. This will be a fertile ground for competition among clients. I say let the market selectand filter through all the different methods to select what should or should not be considered an important change. As an end user I may decide that feeds from a particular person should be very carefully tracked for changes (say some updates to a contract feed), whereas other feeds need only alert me for very large changes (perhaps my cousin's site). Henry On 6 Feb 2005, at 12:47, Eric Scheid wrote: > On 6/2/05 10:16 PM, "Henry Story" wrote: > >> Thinking about it, I would be in favor of clarifying it to be >> "any change should result in a date update". Clients can >> do simple diffs and work out themselves if the changes warrant >> a new date. Presumably clients that see that the only change has been >> to the white space layout may decide that this is not important enough >> to notify their user. > > every day I wade through dozens of changed entries where someone fixes > a > typo or punctuation or other really trivial stuff I wouldn't classify > as > significant, and I'd be surprised if the publisher would too. > > e. From owner-atom-syntax@mail.imc.org Sun Feb 6 08:15:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20105 for ; Sun, 6 Feb 2005 08:15:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16D0ng9054804; Sun, 6 Feb 2005 05:00:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16D0nRR054803; Sun, 6 Feb 2005 05:00:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16D0mhN054655 for ; Sun, 6 Feb 2005 05:00:48 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j16CxTmE027499; Sun, 6 Feb 2005 12:59:34 GMT In-Reply-To: <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> References: <957d7963cd94b91146eb98f51941519e@mac.com> <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5810004ec8a01ba20bbafaa69be98964@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: PaceClarifyDateUpdated Date: Sun, 6 Feb 2005 12:59:29 +0000 To: Henri Sivonen X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 Feb 2005, at 7:15 am, Henri Sivonen wrote: > What do you propose one should do when the current system to which > Atom output is to be added do not record such updates but only records > the date when the bytes changed? > > The modification dates in my current RSS feed are based on the HTTP > Last-Modified value returned by Apache. The current wording of date:updated has exactly the same issue. It's not relevant to this pace. You do have several options a) Use Last-Modified, asserting all changes are "significant" b) Use the same date as atom:published, asserting no changes are "significant" c) Use Last-Modified, since it's SHOULD NOT and not MUST NOT, so if you've consider the interop issues it's fine. (b) is my favourite because it's by far the most compatible. Graham From owner-atom-syntax@mail.imc.org Sun Feb 6 08:22:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20543 for ; Sun, 6 Feb 2005 08:22:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16DEZX2059874; Sun, 6 Feb 2005 05:14:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16DEZen059873; Sun, 6 Feb 2005 05:14:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j16DEYwM059831 for ; Sun, 6 Feb 2005 05:14:35 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 63014 messnum 3855695 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 13:14:29 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 63014) with SMTP; 6 Feb 2005 13:14:29 -0000 Message-ID: <42061831.2040803@dehora.net> Date: Sun, 06 Feb 2005 13:14:25 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> <4205B618.3090603@gmail.com> In-Reply-To: <4205B618.3090603@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > > My challenge with the idea of mustUnderstand in Atom is in trying to > figure out how the heck it would realistically be used for anything > worthwhile. Take blog content for instance, if my blog reader accesses > a feed that contains an entry with a mustUnderstand metadata element > that my reader does not understand, does that mean my reader is not > allowed to show me that content? If so, that's kinda stupid when I can > open the same feed in a browser and view the angle bracket version > without any problem. In SOAP, mustUnderstand makes sense given that the > messages passed around are generally intended for automated consumption > designed to kick of or affect processes in some way. Atom feeds are not > typically going to be used that way. [I don't so much distinction between Atom and SOAP; I suspect Atom and SOAP have intersecting uses.] In my experience too many people believe their data item is critical and thus needs to be non-optional for everyone else. Maybe I don't get it, but giving people veto powers over downstream applications strikes me as imbalanced, especially for metadata. I have zero confidence in mU being used sensibly. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 6 09:56:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27351 for ; Sun, 6 Feb 2005 09:56:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16EkHro067909; Sun, 6 Feb 2005 06:46:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16EkHZ1067908; Sun, 6 Feb 2005 06:46:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brmea-mail-3.sun.com (brmea-mail-3.Sun.COM [192.18.98.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16EkF9i067897 for ; Sun, 6 Feb 2005 06:46:15 -0800 (PST) (envelope-from Tim.Bray@Sun.COM) Received: from esunmail ([129.147.156.34]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j16EkFVu027001 for ; Sun, 6 Feb 2005 07:46:15 -0700 (MST) Received: from fe7 (esunmail [129.147.156.34]) by edgemail1.Central.Sun.COM (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTP id <0IBH0016DVP2DQ@edgemail1.Central.Sun.COM> for atom-syntax@imc.org; Sun, 06 Feb 2005 07:46:14 -0700 (MST) Received: from [192.168.1.17] ([216.113.204.232]) by mail.sun.net (iPlanet Messaging Server 5.2 HotFix 2.02 (built Oct 21 2004)) with ESMTPSA id <0IBH005B9VP1UN@mail.sun.net> for atom-syntax@imc.org; Sun, 06 Feb 2005 07:46:14 -0700 (MST) Date: Sun, 06 Feb 2005 06:46:25 -0800 From: Tim Bray Subject: Re: PaceClarifyDateUpdated In-reply-to: To: Henry Story Cc: Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= Message-id: <34de1890a8f797bc78329707c20fbf25@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.619.2) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <957d7963cd94b91146eb98f51941519e@mac.com> <42056D83.1030002@dehora.net> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT On Feb 6, 2005, at 3:16 AM, Henry Story wrote: > > Thinking about it, I would be in favor of clarifying it to be > "any change should result in a date update". If you will go back and review the correspondence, you will discover a lot of argument, the upshot of which was, different publishers have very different semantics for what they consider an update. I had a posting months and months ago that enumerated a bunch of corner cases (e.g., stylesheet update) that made the whole notion of "any change" rather problematic. There were many who, like you, liked the notion of "objective change" that always changed the date. The reason that we have "updated" with the current language is it reflects the reality that the *only* kind of change that can be cleanly defined is "The publisher thinks it changed." I'm not going to, under my co-chair's hat, heading for the airport to go on vacation, rule this discussion out of order, but it's borderline... -Tim From owner-atom-syntax@mail.imc.org Sun Feb 6 10:47:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01908 for ; Sun, 6 Feb 2005 10:47:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16Fdln0071034; Sun, 6 Feb 2005 07:39:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16Fdldp071033; Sun, 6 Feb 2005 07:39:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16FdkoY071026 for ; Sun, 6 Feb 2005 07:39:46 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j16FdcCi003455; Sun, 6 Feb 2005 10:39:41 -0500 (EST) Message-ID: <42063A19.3030307@intertwingly.net> Date: Sun, 06 Feb 2005 10:39:05 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henry Story CC: bob@wyman.us, "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 agree. Very serious -1 for me. > > I think the versioning element of id works very well. I am using it > in my BlogEd model currently. I think the feed works very well as > an archiving format already. No need to change anything that works well. > > Furthermore I think one should prove that harm is being done by the > id as version feature (which would be difficult to show, because I have > implemented this, Bob has implemented it, and neither of us have > come across a problem). We already have a problem - Bob wanting updated to mean modified. Pardon me for observing that the two individuals mentioned are above average in intelligence, and actually read specifications - an unusual trait. If you produce feeds that contain multiple entries with the same id, there will be people who misunderstand such documents. I do believe that there needs to be some way to say "this is not a feed, but an archive". - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Feb 6 11:16:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04024 for ; Sun, 6 Feb 2005 11:16:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16G7sNa073518; Sun, 6 Feb 2005 08:07:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16G7sMH073517; Sun, 6 Feb 2005 08:07:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16G7rEL073509 for ; Sun, 6 Feb 2005 08:07:53 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j16G6bv5003366; Sun, 6 Feb 2005 16:06:44 GMT In-Reply-To: <42063A19.3030307@intertwingly.net> References: <200502060700.CNY83294@ms8.netsolmail.com> <42063A19.3030307@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: PaceArchiveDocument posted Date: Sun, 6 Feb 2005 16:06:35 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote: > If you produce feeds that contain multiple entries with the same id, > there will be people who misunderstand such documents. > > I do believe that there needs to be some way to say "this is not a > feed, but an archive". Solution: A new atom:archive top level element with normal head and entry children. Difference is multiple instances of entries are allowed with the same id. Each is distinguished by a new atom:version date, that has no semantics other than determining which instance is the newest. Meanwhile, atom:version and multiple instances are explicitly banned from atom:feed. ? Graham From owner-atom-syntax@mail.imc.org Sun Feb 6 11:32:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05002 for ; Sun, 6 Feb 2005 11:32:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GQ0AI075760; Sun, 6 Feb 2005 08:26:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16GQ0Sj075759; Sun, 6 Feb 2005 08:26:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j16GPxmU075749 for ; Sun, 6 Feb 2005 08:25:59 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 8941 messnum 1999221 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 16:25:53 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail09.svc.cra.dublin.eircom.net (qp 8941) with SMTP; 6 Feb 2005 16:25:53 -0000 Message-ID: <4206450E.2070201@dehora.net> Date: Sun, 06 Feb 2005 16:25:50 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> <42063A19.3030307@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote: > >> If you produce feeds that contain multiple entries with the same id, >> there will be people who misunderstand such documents. >> >> I do believe that there needs to be some way to say "this is not a >> feed, but an archive". > > > Solution: > A new atom:archive top level element with normal head and entry > children. Difference is multiple instances of entries are allowed with > the same id. Each is distinguished by a new atom:version date, that has > no semantics other than determining which instance is the newest. > Meanwhile, atom:version and multiple instances are explicitly banned > from atom:feed. An uncomfortable thought (for me). Perhaps this a use-case for @profile. If Mark is following this, he might be able to comment on that. Mark? cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 6 11:35:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05210 for ; Sun, 6 Feb 2005 11:35:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GODOR075668; Sun, 6 Feb 2005 08:24:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16GOCZs075667; Sun, 6 Feb 2005 08:24:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j16GOBj4075659 for ; Sun, 6 Feb 2005 08:24:12 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 25248 messnum 5045546 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 16:24:06 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail04.svc.cra.dublin.eircom.net (qp 25248) with SMTP; 6 Feb 2005 16:24:06 -0000 Message-ID: <420644A2.6000809@dehora.net> Date: Sun, 06 Feb 2005 16:24:02 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceClarifyDateUpdated References: <957d7963cd94b91146eb98f51941519e@mac.com> <42056D83.1030002@dehora.net> <34de1890a8f797bc78329707c20fbf25@sun.com> In-Reply-To: <34de1890a8f797bc78329707c20fbf25@sun.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tim Bray wrote: > > > On Feb 6, 2005, at 3:16 AM, Henry Story wrote: > >> >> Thinking about it, I would be in favor of clarifying it to be >> "any change should result in a date update". No, atom:update is subjective. How UIs support that subjectivity is best left to innovation. I like Graham's wording as it makes me think UI designers will need to give 'save != update' proper consideration. > If you will go back and review the correspondence, you will discover a > lot of argument, the upshot of which was, different publishers have very > different semantics for what they consider an update. I had a posting > months and months ago that enumerated a bunch of corner cases (e.g., > stylesheet update) that made the whole notion of "any change" rather > problematic. There were many who, like you, liked the notion of > "objective change" that always changed the date. The reason that we > have "updated" with the current language is it reflects the reality that > the *only* kind of change that can be cleanly defined is "The publisher > thinks it changed." Strong agreement and as I'm not constrained by being a chair, I'll go further than Tim - using this pace to reopen objective updating is out of order. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 6 11:41:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05758 for ; Sun, 6 Feb 2005 11:41:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GZl0V076313; Sun, 6 Feb 2005 08:35:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16GZlIU076312; Sun, 6 Feb 2005 08:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GZgMc076300 for ; Sun, 6 Feb 2005 08:35:47 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j16GZcbp020241; Sun, 6 Feb 2005 11:35:40 -0500 (EST) Message-ID: <42064739.9060606@intertwingly.net> Date: Sun, 06 Feb 2005 11:35:05 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: Atom Syntax Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> <42063A19.3030307@intertwingly.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote: > >> If you produce feeds that contain multiple entries with the same id, >> there will be people who misunderstand such documents. >> >> I do believe that there needs to be some way to say "this is not a >> feed, but an archive". > > Solution: > A new atom:archive top level element with normal head and entry > children. Difference is multiple instances of entries are allowed with > the same id. Each is distinguished by a new atom:version date, that has > no semantics other than determining which instance is the newest. > Meanwhile, atom:version and multiple instances are explicitly banned > from atom:feed. > > ? Works for me. Presumably, atom:entry elements can have at most one atom:version child element. But, are atom:version elements be required in atom:archives? - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Feb 6 12:01:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08433 for ; Sun, 6 Feb 2005 12:01:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GrB2m077276; Sun, 6 Feb 2005 08:53:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16GrBQQ077275; Sun, 6 Feb 2005 08:53:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16GrAI0077257 for ; Sun, 6 Feb 2005 08:53:10 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j16Gqx412649 for ; Sun, 6 Feb 2005 08:52:59 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBI1KA01.R03; Sun, 6 Feb 2005 08:52:58 -0800 Message-ID: <42064AF1.8030407@aol.net> Date: Sun, 06 Feb 2005 08:50:57 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > I'd rather have held off while we discussed further, but as the > deadline is approaching, here it is. > > Abstract > > Creates a new option for the document element, , which can > contain multiple feeds or instances of the same feed, in order to > archive the states of a feed or feeds and the states of the entries > published while the feed was in each of those states. Specifies that > multiple instances of a resource with the same atom:id is illegal in > Feed Documents, Entry Documents, and if PaceAggregationDocument2 as > adopted, Aggregation Documents, but is legal in Archive Documents. > > Rationale > > 1. Our charter speaks of creating an archive format. > 2. If we wish to be able to archive multiple revisions of an entry > or the contents of a feed's head in a single document, we must either > specify that the atom:id of a resource be repeatable within a document > intended as an archive, or that we invent some other method of > identifying multiple instances of the same entry or feed metadata. > Multiple instances within an archive type document would be simpler. > 3. Multiple versions of an entry or feed in a non-archive document > is unprecedented in syndication formats. In spite of the fact that > changing feed metadata after an entry is published breaks the > connection between the state of the feed metadata at the time of > publishing the entry and the entry, this is how feeds have always > worked, so no exception to the one-feed-instance-per-document rule > need be made for Aggregation Documents--that is a special case > reserved only for archiving. > > See http://www.intertwingly.net/wiki/pie/PaceArchiveDocument for more. > I'm +0 on repeated instances for archives, if it's sufficient for some use case and doesn't delay the draft. But, given that I don't know what the use case for this is, I'm concerned that this is going to be the start of a slew of issues. Some people may be expecting to be able to use the "archive format" to store the entire state of their blog/wiki/whatever, at least as a snapshot. But all the current proposals ignore the crucial issue of how I archive the state of my cat pictures. Seriously -- how can I create a self-contained document that includes both entry and non-entry resources which point at each other? [1]. To be clear, I think this is not something we should tackle at this point, but I fear that the word "archive" may conjure up an image of something you could use for, say, backups. Second, if the intent of tracking state is to be able to go back to a prior version of the feed: This ignores the issues of intra-feed links, for example those of comment feed(s). For example, let's say I get an archive of the history of a (comment) feed. Each entry in this feed will have a URI for the parent entry. But, the parent entry itself can change over time -- the URI is for an entry, not an entry instance. For general URIs, this is just something to live with; but one might reasonably expect an archive format to be able to archive an entry plus its comments together, and if it claims to archive historical changes, to be able to get to a 'state of the site' on demand. Finally, how does one obtain an archive document? A new endpoint? -John Panzer http://journals.aol.com/panzerjohn/abstractioneer [1] This might be a good use for multipart/related and cid:. But that's a much bigger kettle of fish. From owner-atom-syntax@mail.imc.org Sun Feb 6 12:46:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11648 for ; Sun, 6 Feb 2005 12:46:37 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16Hbn5R079748; Sun, 6 Feb 2005 09:37:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16HbnSq079747; Sun, 6 Feb 2005 09:37:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16HbmxV079739 for ; Sun, 6 Feb 2005 09:37:48 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxqLu-0007uo-F2; Sun, 06 Feb 2005 17:37:42 +0000 Message-ID: <420655E9.6020802@franklinmint.fm> Date: Sun, 06 Feb 2005 12:37:45 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Atom Syntax Subject: Re: PaceClarifyDateUpdated References: <957d7963cd94b91146eb98f51941519e@mac.com> <42056D83.1030002@dehora.net> <34de1890a8f797bc78329707c20fbf25@sun.com> <420644A2.6000809@dehora.net> In-Reply-To: <420644A2.6000809@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Tim Bray wrote: > >> The reason that >> we have "updated" with the current language is it reflects the reality >> that the *only* kind of change that can be cleanly defined is "The >> publisher thinks it changed." > > > Strong agreement and as I'm not constrained by being a chair, I'll go > further than Tim - using this pace to reopen objective updating is out > of order. It's certainly out of order (imho), but the Pace doesn't make sense anyway. One of the nice things about RFC2119 is that it provides a couple different ways to say everything. Let's try RECOMMENDED instead of SHOULD: --- The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the producer considers significant. Therefore, it is NOT RECOMMENDED that other modifications result in a changed atom:updated value. --- uh, yeah... Robert Sayre From owner-atom-syntax@mail.imc.org Sun Feb 6 14:43:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20219 for ; Sun, 6 Feb 2005 14:43:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16JLA4q086123; Sun, 6 Feb 2005 11:21:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16JLAV4086122; Sun, 6 Feb 2005 11:21:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m70195e42.tmodns.net [66.94.25.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16JL9xS086091 for ; Sun, 6 Feb 2005 11:21:09 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 446EA99E0; Sun, 6 Feb 2005 13:15:48 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23857-04; Sun, 6 Feb 2005 13:15:46 -0600 (CST) Received: from boblaptop (unknown [10.255.205.54]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sun, 6 Feb 2005 13:15:46 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Sam Ruby'" , "'Henry Story'" Cc: , "'Antone Roundy'" , Subject: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 14:20:55 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42063A19.3030307@intertwingly.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMYhukOLhTaP1RRt+DP0CZmuJrGwAGJcvw Message-Id: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > If you produce feeds that contain multiple entries with the same > id, there will be people who misunderstand such documents. So what? If they initially misunderstand, they will eventually learn how to do it properly. In any case, I think you miswrote the quoted sentence. I believe you are talking about "feed documents" not "feeds". The simple fact is that according to the Atom specification as it stands and according to the common useage in the syndication world, feeds frequently have multiple entries with the same atom:id. By "feed" I mean, of course, the abstract thing of which a feed document presents a subset. The issue here is not whether *feeds* can contain multiple same-id entries, but rather whether feed documents can do so. The *real* issue here is that we never had the "BAG" discussions that I was pleading for back in the summer... A "Blog Architecture" would have answered questions like "What is a Feed?" "What is an entry?" how does a Feed differ from a Feed Document, etc... If nothing else, we might have come to use a common vocabulary. In this particular debate, the core issue is "What is a Feed Document?" I have long contended that a Feed Document is a "sliding window" on a feed. Sayre and others have said that a Feed Document is "a representation of the current state of a set of entries." The difference is significant. For instance, if you accept the "sliding window" view, then since a feed (the abstract thing) can have multiple instances of entries with the same atom:id, then it is obvious that a Feed Document should have the same property. On the other hand, if you accept the "current state" definition of a Feed Document, you end up saying that while a Feed can have multiple same-id instances, it is clear that a Feed Document cannot since there is only one "current state" of a resource at any one time. In either case, the definition of "Feed Document" implies the answer, without debate, to the question: "Can a Feed Document contain multiple entries with the same atom:id?" Had we dealt with architectural issues, this debate would not and could not be happening. The same can be said about a number of other issues before us now. Sayre and others have, for instance, complained regularly about the lack of agreed definitions concerning "What is an Entry...", etc. Our terminology is sloppy. We haven't done our jobs well. I contend that we should adopt the sliding window definition of a feed simply because it is the most useful and easiest to implement. It makes "archiving" simple, it allows those who are anal about getting "every change" to get them, and it makes it possible for us to implement bandwidth saving measures such as RFC3229+feed. None of these things are possible, without the creation of a special "archive" type, if one adopts the "current state" view. Given that the "sliding window" view addresses a wider variety of requirements, I think we should adopt it as the primary view. With sliding windows, the only thing you need to do to update a feed document is insert at its head the new or changed entry. (You could also just append to the tail of the file. Order should not be significant in an Atom file...) On the other hand, the "current state" view requires that you scan the current Feed Document and remove any pre-existing entry that has the same atom:id as the one you are inserting. The difference in Feed Document updating may not seem to be big, however, it becomes significant when we consider things like the RFC3229+feed that is currently responsible for *massive* bandwidth savings for those that use it. RFC3229+feed, as written, assumes a "sliding window" view of Feed Documents and can be simply implemented by simply associating ETags with the various points in a document at which entries are inserted. Constructing the "diff" of a feed document is then simply a question of indexing back into the Feed Document to the ETag in question and copying all the data inserted after the ETag. However, if the "current state" view of a feed is required, then it becomes necessary on entry insertion or on retrieval to process each entry in the sliding window to filter out duplicate atom:ids. The result is more processing for the server and a great deal more complexity in the implementation. My fear is that the increased complexity (which probably requires a database approach -- not just a sequential file with "ETag cursors" pointing in to it) is sufficient that people won't implement RFC3229+feed. The result would be wasted bandwidth, etc... Of course, adopting "current state" instead of "sliding window" also means that we have to invent the atom:archive type so that we can produce the sliding window view which is implied by the archive requirement. Thus, we're making things more complex by offering both "current state" and "sliding window" views. It has been argued by a number of people that we can't adopt "sliding window" since the ability to have multiple instances of a since entry in a Feed document is "unprecedented" in the history of blogging and syndication!!! This is, of course, a completely false statement. The reality is that in RSS and Atom feed documents in use today, one often sees the same id or guid being used for multiple entries. In fact, the most popular id or quid is "null" or nothing... The result has, of course, been that virtually no existing aggregators actually do anything useful with ids or Guids (unless they are in RSS V2.0 and flagged as permalinks.) This lack of use for non-permalink guids resulted from the under-specification in previous versions of syndication formats as well as the fact that GUIDs were generally optional. But, an essential element of the Atom format is that atom:id is *required* and thus can be used for useful purposes. It is that expectation that an atom:id or guid is *useful* that is unprecedented in Atom... In any case, why in the world would the fact that something is "unprecedented" be a bar to our adopting it? Are we forbidden to innovate? Must we propagate all the errors of the past? Anyway, I am convinced that the "current state" view is less useful then the "sliding window" view. The current proposals to define an "archive" type to patch "sliding window" into Atom are excellent indications that I'm right... I know others disagree... I also realize that not many people will actually read this whole message. Ah well... bob wyman From owner-atom-syntax@mail.imc.org Sun Feb 6 14:59:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21452 for ; Sun, 6 Feb 2005 14:59:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16JliBG088101; Sun, 6 Feb 2005 11:47:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16Jlimt088100; Sun, 6 Feb 2005 11:47:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mailrelay.t-mobile.com (m70195e42.tmodns.net [66.94.25.112]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16Jlhhq088081 for ; Sun, 6 Feb 2005 11:47:43 -0800 (PST) (envelope-from bob@wyman.us) Received: from localhost (localhost [127.0.0.1]) by mailrelay.t-mobile.com (Postfix) with ESMTP id 7B0BE99B2; Sun, 6 Feb 2005 13:42:21 -0600 (CST) Received: from mailrelay.t-mobile.com ([127.0.0.1]) by localhost (mailrelay.t-mobile.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24038-10; Sun, 6 Feb 2005 13:42:20 -0600 (CST) Received: from boblaptop (unknown [10.255.205.54]) by mailrelay.t-mobile.com (Postfix) with ESMTP; Sun, 6 Feb 2005 13:42:20 -0600 (CST) Reply-To: From: "Bob Wyman" To: "'Roger B.'" , Cc: Subject: RE: Open Comments..... Date: Sun, 6 Feb 2005 14:47:29 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <540e373205020602137943c113@mail.gmail.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMNPSD9gh0yYqESriitndbdWG61gATQEKA Message-Id: <20050206194221.7B0BE99B2@mailrelay.t-mobile.com> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roger Benningfield wrote: > Bob: Bah, bug, and hum. Comments are just micro-message boards, Wrong... Comments are just entries that are normally presented to users in what appear to be micro-message boards. As is usually the case in software design, it is very important to ensure that you don't allow attributes of the presentation to overly influence the way data is stored or represented. The goal should be to ensure that the desired presentations are possible, however, if you allow any one presentation to overly influence the storage and processing design, you will almost inevitably prevent the use of alternative presentations. That would not be a good thing. Encapsulating comments in "mini-feeds" or nested feeds certainly allows one to present comments as though they were micro-message boards. However, doing that prevents or makes it difficult to implement distributed commenting without adding new facilities and mechanisms. On the other hand, if you design for distributed comments and encode the relationship between entries via metadata, you can still present a micro-message board with little difficulty. Whether or not you support distributed commenting then becomes a question of implementation choice, not something which requires new specification. Basically, what I'm saying here is that indicating the type and relationship between entries and comments via metadata is vastly more general and useful then doing the same by using file structure to indicate the same. Given that there is little cost to using the metadata approach, I argue for it. > message boards have been getting along just fine for many, many > years without the help of PubSub or any other third party. You are, of course, quite correct. However, now that we have PubSub, Google, and a variety of other tools that can be used to find referential connections between objects on the web, it seems like it would make sense to attempt to exploit these new tools to provide better or different services to our users. I don't argue that message board require the services we provide, only that it would be a shame to implement a system that made it hard for some innovative developer to use these services. > More importantly, a reply that exists within the context of the > source and a reply that exists in another space entirely are very > different things... they're written differently, perceived > differently, and often aim for different goals. I couldn't agree with you more. The big difference is, of course, that a reply that exists within the administrative context of the source has some measure of "authorization" attached to it. i.e. the maintainer of the context has authorized, permitted or tolerated the reply to exist in that context. However, this does not argue against implementing support for replies that do not exist within the same administrative context as the source. If we have a method that can support both types of reply better than another method that is best for only one type, then I think we should adopt the more general method. It then becomes a property of applications to determine how to distinguish between the two types. (Perhaps different colors, icons, etc.?) We've seen the same distinction as is seen here in the difference between normal trackback (which allows any random person to insert a back link into a blog) and the sort of "automated trackback" that you get if you link to the Technorati Cosmos or a PubSub link feed in your blog. Just as you suggest, the embedded trackbacks and the "computed trackbacks" are thought of differently, perceived differently, etc. Nonetheless, both types have proven to be useful. If we can support both with a single method -- why not do it? bob wyman From owner-atom-syntax@mail.imc.org Sun Feb 6 15:31:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24867 for ; Sun, 6 Feb 2005 15:31:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KMuhc090329; Sun, 6 Feb 2005 12:22:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16KMujq090328; Sun, 6 Feb 2005 12:22:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KMuI9090311 for ; Sun, 6 Feb 2005 12:22:56 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 6371 invoked by uid 17064); 6 Feb 2005 20:22:46 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.8.44]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 6 Feb 2005 20:22:46 -0000 In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <56acd4f2c13317327d3b951c1a29240f@bblfish.net> Content-Transfer-Encoding: 7bit Cc: "'Antone Roundy'" , , "'Sam Ruby'" From: Henry Story Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 21:22:21 +0100 To: X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have read your message in full, and I am totally convinced by your argument. I think the sliding window view is clear, simple and powerful. (I also think it can easily be modeled in RDF.) Many +1's from me. Henry Story On 6 Feb 2005, at 20:20, Bob Wyman wrote: > The current proposals to define an "archive" > type to patch "sliding window" into Atom are excellent indications > that I'm > right... I know others disagree... I also realize that not many people > will > actually read this whole message. Ah well... From owner-atom-syntax@mail.imc.org Sun Feb 6 16:07:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27523 for ; Sun, 6 Feb 2005 16:07:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KxIIh092149; Sun, 6 Feb 2005 12:59:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16KxI5l092148; Sun, 6 Feb 2005 12:59:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KxDQo092118 for ; Sun, 6 Feb 2005 12:59:18 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j16Kwnh03155 for ; Sun, 6 Feb 2005 12:58:49 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBICY003.303; Sun, 6 Feb 2005 12:58:48 -0800 Message-ID: <42068491.1050504@aol.net> Date: Sun, 06 Feb 2005 12:56:49 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Sam Ruby'" , "'Henry Story'" , "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: >I have long contended that a Feed Document is a "sliding window" >on a feed. Sayre and others have said that a Feed Document is "a >representation of the current state of a set of entries." > Agreed that these are different and that defining which is acceptable/required is needed. For example, if a feed _must be_ a "sliding window", that would imply that a database-backed bloggin system_must_ keep track of the past state of Entries in order to be able to generate a feed on demand. If a feed _must be_ a "representation of the current state of a set of entries", then intermediate aggregators _must_ do duplicate detection and decide which version to pass on. I can see pros and cons either way. But I think that failing to decide would be worse than picking either: It would result in subtle confusion and interoperability headaches. So I'm +1 on picking one and documenting it. John Panzer http://journals.aol.com/panzerjohn/abstractioneer From owner-atom-syntax@mail.imc.org Sun Feb 6 16:07:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27576 for ; Sun, 6 Feb 2005 16:07:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KxFp6092139; Sun, 6 Feb 2005 12:59:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16KxFk4092138; Sun, 6 Feb 2005 12:59:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16KxEdR092132 for ; Sun, 6 Feb 2005 12:59:15 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j16Kx9ee022407; Sun, 6 Feb 2005 15:59:10 -0500 (EST) Message-ID: <420684FC.9080309@intertwingly.net> Date: Sun, 06 Feb 2005 15:58:36 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Henry Story'" , "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Sam Ruby wrote: > >>If you produce feeds that contain multiple entries with the same >>id, there will be people who misunderstand such documents. > > So what? If they initially misunderstand, they will eventually learn > how to do it properly. It is quite possible that "they" outnumber "you". I have seen the spec definition of elements in feed formats become /overtaken by events/, and eventually become defined by the common usage as opposed to the spec usage. [snip] > In this particular debate, the core issue is "What is a Feed > Document?" I have long contended that a Feed Document is a "sliding window" > on a feed. Sayre and others have said that a Feed Document is "a > representation of the current state of a set of entries." The difference is > significant. [snip] > Anyway, I am convinced that the "current state" view is less useful > then the "sliding window" view. The current proposals to define an "archive" > type to patch "sliding window" into Atom are excellent indications that I'm > right... I know others disagree... I also realize that not many people will > actually read this whole message. Ah well... Who is "right" is not important to me. If there are two different approaches, and those differences are "significant", I want those differences to be explicit in the document. My weblog software does not maintain a historical perspective. To the best of my knowledge, neither does Blogger, MovableType, TypePad, Blosxom, WordPress, etc. Feeds from such tools will inevitably, therefore, represent a "current state" view. Nor, do I expect that these tool manufactures have any interest in learning "how to do it properly". - Sam Ruby From owner-atom-syntax@mail.imc.org Sun Feb 6 16:27:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29112 for ; Sun, 6 Feb 2005 16:27:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LHUwe093331; Sun, 6 Feb 2005 13:17:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16LHUg7093330; Sun, 6 Feb 2005 13:17:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LHTpF093242 for ; Sun, 6 Feb 2005 13:17:29 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 7 Feb 2005 10:17:43 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 07 Feb 2005 08:16:56 +1100 Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/2/05 6:20 AM, "Bob Wyman" wrote: > In this particular debate, the core issue is "What is a Feed > Document?" I have long contended that a Feed Document is a "sliding window" > on a feed. Sayre and others have said that a Feed Document is "a > representation of the current state of a set of entries." The difference is > significant. For instance, if you accept the "sliding window" view, then > since a feed (the abstract thing) can have multiple instances of entries > with the same atom:id, then it is obvious that a Feed Document should have > the same property. On the other hand, if you accept the "current state" > definition of a Feed Document, you end up saying that while a Feed can have > multiple same-id instances, it is clear that a Feed Document cannot since > there is only one "current state" of a resource at any one time. just another data-point: I've long worked from the definition that a Feed Document is "a representation of a set of entries". None of this "current state" malarky, and no "sliding window" requirement. Both Archive Documents and Sliding Window Feed Documents can exist in this model. e. From owner-atom-syntax@mail.imc.org Sun Feb 6 16:57:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01477 for ; Sun, 6 Feb 2005 16:57:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LoHgm096531; Sun, 6 Feb 2005 13:50:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16LoHK1096530; Sun, 6 Feb 2005 13:50:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LoGFM096521 for ; Sun, 6 Feb 2005 13:50:17 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.3]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CxuIA-0001TB-Fy; Sun, 06 Feb 2005 21:50:06 +0000 Message-ID: <42069111.6090906@franklinmint.fm> Date: Sun, 06 Feb 2005 16:50:09 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Sam Ruby'" , "'Henry Story'" , "'Antone Roundy'" , atom-syntax@imc.org Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Anyway, I am convinced that the "current state" view is less useful > then the "sliding window" view. The current proposals to define an "archive" > type to patch "sliding window" into Atom are excellent indications that I'm > right... I know others disagree... I also realize that not many people will > actually read this whole message. Ah well... It is irritating but necessary to have this discussion right now. Thank you for starting it. At the end of it, the first paragraph of The Atom Syndication Format should contain less handwaving, at the cost of some astronautic emails like this one. I contend the "sliding window" and "current state" positions aren't really opposed at all. Let's start with your own site: http://bobwyman.pubsub.com/ http://bobwyman.pubsub.com/main/index.rdf The naming convention should be a tipoff. Users expect a machine readable version of your index page. It would be confusing for the index page of your site to contain multiple copies of the same entry, and I contend it is similarly so for the feed document. So, how to record state transitions PubSub has witnessed between hits from a subscribing client? I would simulate a sequence of HTTP GET requests: -------------------------------------- ... ... ... ... ... ... I think we should make feed/id mandatory for two reasons: 1.) If you can't generate an id for your feed, you're never going to succeed with the entries, and it will make a useful base string, like your address does for email. 2.) Multiple feed elements could have the same atom:id, simulating multiple GETs. -------------------------------------- Do we have to spec this now? No. > It has been argued by a number of people that we can't adopt > "sliding window" since the ability to have multiple instances of a since > entry in a Feed document is "unprecedented" in the history of blogging and > syndication!!! This is, of course, a completely false statement. The reality > is that in RSS and Atom feed documents in use today, one often sees the same > id or guid being used for multiple entries. In fact, the most popular id or > quid is "null" or nothing... The result has, of course, been that virtually > no existing aggregators actually do anything useful with ids or Guids > (unless they are in RSS V2.0 and flagged as permalinks.) This is, of course, a completely false statement. Here is NetNewsWire's sync data: tag:www.franklinmint.fm,2004://1.187 created 2004-09-23T12:26:11Z flagged followed read Also, Thunderbird uses them to compose its "message-id". I could go on. Robert Sayre From owner-atom-syntax@mail.imc.org Sun Feb 6 17:03:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02123 for ; Sun, 6 Feb 2005 17:03:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LvDwq096906; Sun, 6 Feb 2005 13:57:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16LvDbQ096905; Sun, 6 Feb 2005 13:57:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16LvCr6096887 for ; Sun, 6 Feb 2005 13:57:13 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j16LuMxi018531; Sun, 6 Feb 2005 21:56:28 GMT In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9957491ba632940afbd8307c3343c65e@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 20:47:38 +0000 To: bob@wyman.us X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > feeds frequently have multiple entries with the same atom:id Can you name one example that wasn't written by an arsehole trying to trick aggregators into behaving in a way they weren't designed to? > I have long contended that a Feed Document is a "sliding window" > on a feed. Sayre and others have said that a Feed Document is "a > representation of the current state of a set of entries." False dichotomy. It's a sliding window of current states. You've started with your conclusion and worked backwards. The whole argument is invalid, no matter who many words you asterisk. > I also realize that not many people will actually read this whole > message. Ah well... This is one of those things were anyone that disagrees gets told they haven't read it, just don't get "it". Graham From owner-atom-syntax@mail.imc.org Sun Feb 6 17:07:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02464 for ; Sun, 6 Feb 2005 17:07:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16M0Xnt097101; Sun, 6 Feb 2005 14:00:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16M0XAW097100; Sun, 6 Feb 2005 14:00:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16M0ScF097078 for ; Sun, 6 Feb 2005 14:00:32 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j16M0K422272 for ; Sun, 6 Feb 2005 14:00:20 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBIFSJ02.F03; Sun, 6 Feb 2005 14:00:19 -0800 Message-ID: <420692FC.6000108@aol.net> Date: Sun, 06 Feb 2005 13:58:20 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------090400050704050100070303" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------090400050704050100070303 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 7/2/05 6:20 AM, "Bob Wyman" wrote: > > > >>In this particular debate, the core issue is "What is a Feed >>Document?" I have long contended that a Feed Document is a "sliding window" >>on a feed. Sayre and others have said that a Feed Document is "a >>representation of the current state of a set of entries." The difference is >>significant. For instance, if you accept the "sliding window" view, then >>since a feed (the abstract thing) can have multiple instances of entries >>with the same atom:id, then it is obvious that a Feed Document should have >>the same property. On the other hand, if you accept the "current state" >>definition of a Feed Document, you end up saying that while a Feed can have >>multiple same-id instances, it is clear that a Feed Document cannot since >>there is only one "current state" of a resource at any one time. >> >> > >just another data-point: I've long worked from the definition that a Feed >Document is "a representation of a set of entries". None of this "current >state" malarky, and no "sliding window" requirement. Both Archive Documents >and Sliding Window Feed Documents can exist in this model. > Since an entry is identified uniquely by its atom:id (though it can have different states at different times); And, since it's not possible to add more than one of any unique thing to a (mathematical) set; And, since Sliding Window may require adding two elements with the same atom:id to the same feed: I'm not sure how Sliding Window can exist in this model. Maybe you meant "a set of entry instances"? -John --------------090400050704050100070303 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Scheid wrote: 
On 7/2/05 6:20 AM, "Bob Wyman" <bob@wyman.us> wrote:

  
In this particular debate, the core issue is "What is a Feed
Document?" I have long contended that a Feed Document is a "sliding window"
on a feed. Sayre and others have said that a Feed Document is "a
representation of the current state of a set of entries." The difference is
significant. For instance, if you accept the "sliding window" view, then
since a feed (the abstract thing) can have multiple instances of entries
with the same atom:id, then it is obvious that a Feed Document should have
the same property. On the other hand, if you accept the "current state"
definition of a Feed Document, you end up saying that while a Feed can have
multiple same-id instances, it is clear that a Feed Document cannot since
there is only one "current state" of a resource at any one time.
    

just another data-point: I've long worked from the definition that a Feed
Document is "a representation of a set of entries". None of this "current
state" malarky, and no "sliding window" requirement. Both Archive Documents
and Sliding Window Feed Documents can exist in this model.
Since an entry is identified uniquely by its atom:id (though it can have different states at different times);
And, since it's not possible to add more than one of any unique thing to a (mathematical) set;
And, since Sliding Window may require adding two <entry> elements with the same atom:id to the same feed:

I'm not sure how Sliding Window can exist in this model.  Maybe you meant "a set of entry instances"?

-John
--------------090400050704050100070303-- From owner-atom-syntax@mail.imc.org Sun Feb 6 17:23:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03442 for ; Sun, 6 Feb 2005 17:23:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16MGups098839; Sun, 6 Feb 2005 14:16:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16MGuEK098838; Sun, 6 Feb 2005 14:16:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail06.svc.cra.dublin.eircom.net (mail06.svc.cra.dublin.eircom.net [159.134.118.22]) by above.proper.com (8.12.11/8.12.9) with SMTP id j16MGtK1098829 for ; Sun, 6 Feb 2005 14:16:55 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 73387 messnum 2835324 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 22:16:48 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail06.svc.cra.dublin.eircom.net (qp 73387) with SMTP; 6 Feb 2005 22:16:48 -0000 Message-ID: <4206974B.2000000@dehora.net> Date: Sun, 06 Feb 2005 22:16:43 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: <20050206191548.446EA99E0@mailrelay.t-mobile.com> In-Reply-To: <20050206191548.446EA99E0@mailrelay.t-mobile.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > In this particular debate, the core issue is "What is a Feed > Document?" I have long contended that a Feed Document is a "sliding window" > on a feed. Sayre and others have said that a Feed Document is "a > representation of the current state of a set of entries." The difference is > significant. For instance, if you accept the "sliding window" view, then > since a feed (the abstract thing) can have multiple instances of entries > with the same atom:id, then it is obvious that a Feed Document should have > the same property. On the other hand, if you accept the "current state" > definition of a Feed Document, you end up saying that while a Feed can have > multiple same-id instances, it is clear that a Feed Document cannot since > there is only one "current state" of a resource at any one time. If I don't take a technical interpretation of the word 'set', there's no useful distinction (which is to say I don't see a need to specify one over the other). > In either case, the definition of "Feed Document" implies the > answer, without debate, to the question: "Can a Feed Document contain > multiple entries with the same atom:id?" Had we dealt with architectural > issues, this debate would not and could not be happening. With no malice: you're assuming we'd be finished dealing with the architectural issues by now. > Of course, adopting "current state" instead of "sliding window" also > means that we have to invent the atom:archive type so that we can produce > the sliding window view which is implied by the archive requirement. Thus, > we're making things more complex by offering both "current state" and > "sliding window" views. The archive element is being invented so people can treat the entire lump of XML as an archive. It's a control code, not an artefact of a model. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 6 17:25:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03556 for ; Sun, 6 Feb 2005 17:25:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16MIIUi098906; Sun, 6 Feb 2005 14:18:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16MIIsF098905; Sun, 6 Feb 2005 14:18:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail04.svc.cra.dublin.eircom.net (mail04.svc.cra.dublin.eircom.net [159.134.118.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j16MIHfB098898 for ; Sun, 6 Feb 2005 14:18:18 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 20136 messnum 5050007 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 6 Feb 2005 22:18:11 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail04.svc.cra.dublin.eircom.net (qp 20136) with SMTP; 6 Feb 2005 22:18:11 -0000 Message-ID: <4206979F.6020603@dehora.net> Date: Sun, 06 Feb 2005 22:18:07 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: <420692FC.6000108@aol.net> In-Reply-To: <420692FC.6000108@aol.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Panzer wrote: > Since an entry is identified uniquely by its atom:id (though it can have > different states at different times); > And, since it's not possible to add more than one of any unique thing to > a (mathematical) set; > And, since Sliding Window may require adding two elements with > the same atom:id to the same feed: > > I'm not sure how Sliding Window can exist in this model. Maybe you > meant "a set of entry instances"? This is exactly what I meant in my last mail. The word 'set' is being taken too seriously. I don't think that's warranted. cheers Bill From owner-atom-syntax@mail.imc.org Sun Feb 6 17:31:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03929 for ; Sun, 6 Feb 2005 17:31:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16MOuaL099346; Sun, 6 Feb 2005 14:24:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16MOu6v099345; Sun, 6 Feb 2005 14:24:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16MOuWp099338 for ; Sun, 6 Feb 2005 14:24:56 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 749FB4F303; Sun, 6 Feb 2005 17:24:53 -0500 (EST) Date: Sun, 6 Feb 2005 17:24:53 -0500 From: Dan Brickley To: John Panzer Cc: Eric Scheid , Atom Syntax Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Message-ID: <20050206222453.GM16105@homer.w3.org> References: <420692FC.6000108@aol.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <420692FC.6000108@aol.net> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.6+20040907i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * John Panzer [2005-02-06 13:58-0800] > Since an entry is identified uniquely by its atom:id (though it can have > different states at different times); As I understand the Web, the "REST" concepts that underpin HTTP are quite happy with their being multiple representations of the selfsame resource *at the time*. The state captured in the documents that fly around the Web can be one of several that are associated with a common abstract entity. I'm not sure how this fits with the "sliding window" vs "current state" views of Atom. I guess I've always seen feeds as just being documents that are about some other documents, and whose state and selection of document coverage / detail is naturally going to vary depending on the sort of site we're dealing with. Dan From owner-atom-syntax@mail.imc.org Sun Feb 6 18:22:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08142 for ; Sun, 6 Feb 2005 18:22:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16NA8fx002362; Sun, 6 Feb 2005 15:10:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j16NA8Zh002361; Sun, 6 Feb 2005 15:10:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao05.cox.net (fed1rmmtao05.cox.net [68.230.241.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j16NA37A002346 for ; Sun, 6 Feb 2005 15:10:03 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050206230959.SZH11322.fed1rmmtao05.cox.net@[192.168.0.100]>; Sun, 6 Feb 2005 18:09:59 -0500 In-Reply-To: <20050206222453.GM16105@homer.w3.org> References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax , John Panzer , Eric Scheid From: "Roy T. Fielding" Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 15:09:57 -0800 To: Dan Brickley X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote: > * John Panzer [2005-02-06 13:58-0800] > >> Since an entry is identified uniquely by its atom:id (though it can >> have >> different states at different times); > > As I understand the Web, the "REST" concepts that underpin HTTP > are quite happy with their being multiple representations of > the selfsame resource *at the time*. Also at multiple times. Yes, it's all about time, but also about resources. The entry is a resource, and that resource may have multiple representations at a single time (atom, rss1, rss2) and also over different times. A resource has a single state at one point in time, but may have different states over time (in some case they must have different states over time because that is the essence of what makes them a resource, just as a clock is expected to have different state). URIs identify resources, not necessarily singular states. Feeds are sliding window resources, but their representations do not slide -- they are fixed at a given point in time. If it is reasonable to say that, at any single point in time, only one representation of a given entry can appear in the feed's representation, then the only valid representation of a feed is one that does not contain any duplicate entry id's. An atom:feed document is a representation of a single feed resource at a single point in time. Aggregators do not consume feed resources -- they consume an iterative set of overlapping feed representations. Aggregators are therefore required by Atom to only include the "latest" version of an entry within their own resource representations. I believe that these requirements reflect the desires of most of the participants in this working group, so it seems to me that the question has been answered. Cheers, Roy T. Fielding Chief Scientist, Day Software From owner-atom-syntax@mail.imc.org Sun Feb 6 19:29:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13080 for ; Sun, 6 Feb 2005 19:29:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j170Ix97006625; Sun, 6 Feb 2005 16:18:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j170IxOD006624; Sun, 6 Feb 2005 16:18:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j170IaRB006518 for ; Sun, 6 Feb 2005 16:18:58 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [203.30.247.18] by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Mon, 7 Feb 2005 13:18:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 07 Feb 2005 11:18:03 +1100 Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <420692FC.6000108@aol.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/2/05 8:58 AM, "John Panzer" wrote: > Since an entry is identified uniquely by its atom:id (though it can have > different states at different times); And, since it's not possible to add more > than one of any unique thing to a (mathematical) set; And, since Sliding > Window may require adding two elements with the same atom:id to the > same feed: > > I'm not sure how Sliding Window can exist in this model. Maybe you meant "a > set of entry instances"? > I didn't specifically define "set" to be the more limited mathematical definition. Think dining room set -- a collection of otherwise identical items (chairs). e. From owner-atom-syntax@mail.imc.org Sun Feb 6 20:19:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16211 for ; Sun, 6 Feb 2005 20:19:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j171BivD010649; Sun, 6 Feb 2005 17:11:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j171BiT0010648; Sun, 6 Feb 2005 17:11:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (r2d2.aoltw.net [64.236.137.26]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j171BdLx010631 for ; Sun, 6 Feb 2005 17:11:44 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j171BTh10842 for ; Sun, 6 Feb 2005 17:11:30 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBION502.706; Sun, 6 Feb 2005 17:11:29 -0800 Message-ID: <4206BFCA.5050208@aol.net> Date: Sun, 06 Feb 2005 17:09:30 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010707010400030803060407" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------010707010400030803060407 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Scheid wrote: >On 7/2/05 8:58 AM, "John Panzer" wrote: > > >>... >> >> > >I didn't specifically define "set" to be the more limited mathematical >definition. Think dining room set -- a collection of otherwise identical >items (chairs). > > Okay. I suggest we use the word "collection" for this concept to avoid confusion. You're saing that a Feed Document is "a representation of a collection of entries"; I don't think anyone would argue with this. -John --------------010707010400030803060407 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Eric Scheid wrote: 
On 7/2/05 8:58 AM, "John Panzer" <jpanzer@aol.net> wrote:
  
...
    

I didn't specifically define "set" to be the more limited mathematical
definition. Think dining room set -- a collection of otherwise identical
items (chairs).
Okay.  I suggest we use the word "collection" for this concept to avoid confusion.  You're saing that a Feed Document is "a representation of a collection of entries"; I don't think anyone would argue with this.

-John

--------------010707010400030803060407-- From owner-atom-syntax@mail.imc.org Sun Feb 6 20:46:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17807 for ; Sun, 6 Feb 2005 20:46:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j171WWoc012152; Sun, 6 Feb 2005 17:32:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j171WWA2012151; Sun, 6 Feb 2005 17:32:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j171WVDJ012135 for ; Sun, 6 Feb 2005 17:32:31 -0800 (PST) (envelope-from joe.gregorio@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so1142100rng for ; Sun, 06 Feb 2005 17:32:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=FnIlqc2NZs00XAOfqHs7Zi4ePMu96aayS8p+ffSD1Y/ameXfPaTS09KVPE6poHszYeYN6Yu8+MLzJY9A5ATvOaD5IHqI4ooT4VeH9zyspnro2XhmvXPwe6DaWIT1ZiV1nQzl4OV8AYLBV6/g6aw1WzY8loSEOsEUoxETof+2SIA= Received: by 10.38.13.29 with SMTP id 29mr11378rnm; Sun, 06 Feb 2005 17:32:26 -0800 (PST) Received: by 10.38.151.18 with HTTP; Sun, 6 Feb 2005 17:32:26 -0800 (PST) Message-ID: <3f1451f505020617327e31fb80@mail.gmail.com> Date: Sun, 6 Feb 2005 20:32:26 -0500 From: Joe Gregorio Reply-To: Joe Gregorio To: Eric Scheid Subject: Re: dereferencability of ? Cc: Atom Syntax In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sun, 06 Feb 2005 16:21:25 +1100, Eric Scheid wrote: > > consider > > > > assume for the moment that is a valid scheme > > is that kind of URI something we want to allow in link/@href? I see no problem with the above example. The usage of a URI in no way mandates 'dereferenceability'. -joe -- Joe Gregorio http://bitworking.org From owner-atom-syntax@mail.imc.org Sun Feb 6 21:51:32 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23330 for ; Sun, 6 Feb 2005 21:51:31 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j172gb2a017990; Sun, 6 Feb 2005 18:42:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j172gbig017989; Sun, 6 Feb 2005 18:42:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j172gVGr017971 for ; Sun, 6 Feb 2005 18:42:31 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j172gJTh020716; Sun, 6 Feb 2005 21:42:24 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COE68341; Sun, 6 Feb 2005 21:42:18 -0500 (EST) Message-Id: <200502070242.COE68341@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Roy T. Fielding'" , "'Dan Brickley'" Cc: "'Atom Syntax'" , "'John Panzer'" , "'Eric Scheid'" Subject: RE: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 21:42:16 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMpAW30tpuZ/XMS4+7Kggc/8ik0AAFThgg Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Roy T. Fielding wrote: > Aggregators do not consume feed resources -- they consume an > iterative set of overlapping feed representations. This is only true of pull based aggregators that poll for feeds. None of the aggregators that I use are polling based. I use the PubSub Sidebars and the Gush aggregator built by 2entwine.com. These aggregators consume streams of entries that are pushed to them using the "Atom over HTTP" protocol. See: http://www.ietf.org/internet-drafts/draft-saintandre-atompub-notify-02.txt As I've said on numerous occasions: "It's about the Entries, Stupid!" The whole "feed" business is simply an artifact of the polling-based model of syndication. The Entry should be the core element of Atom, not the Feed. The Feed, as a collection, is there to serve the Entries -- not the reverse. Feeds are just a way of bundling up Entries while the server is waiting for readers to poll for results. But, what readers are fundamentally interested in is the entries in the feed, not the feed itself. The polling oriented, feed-based model of syndication results in significant waste of network bandwidth and processing resources as well as introducing significant latencies between when items are published and when they are accessed by readers. (i.e. average latency is 1/2 the polling frequency.) While the use of push-based aggregators may not be widespread, it does not make sense, I think, to bind Atom to the inefficient, high-latency polling model when we know that there is a workable alternative approach -- which is far superior in at least some important applications of syndication. A push-fed aggregator never sees feeds -- except on startup when it might read a feed in order to catch-up on entries that were published while it was off-line (if the push server doesn't do guaranteed, queued delivery). From the point of view of a push-fed aggregator, a feed is simply a log of the stream of entries that were pushed to it or would have been pushed to it if it had been online. i.e. it is a static archive of the dynamic stream. To touch on another issue recently discussed: A push-fed aggregator, because it sees streams of entries, not feeds, simply cannot exploit or even discover any "feed order" information other than pure chronological order. To require that any significance be given to "order in feed" is essentially the same as prohibiting the use of Atom in poll-fed aggregators. In a push-fed aggregator that sees a steam of entries, it is essential that any inter-Entry relationships be specified within the entries themselves. No other information is available... The Atom spec will live or should live for a long time. It would not, I think, be good to tie it too tightly to the inefficient, high-latency polling model -- even though that model is the most commonly used today. bob wyman From owner-atom-syntax@mail.imc.org Sun Feb 6 21:56:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23531 for ; Sun, 6 Feb 2005 21:56:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j172ogXL018586; Sun, 6 Feb 2005 18:50:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j172ogsm018585; Sun, 6 Feb 2005 18:50:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j172ofY6018578 for ; Sun, 6 Feb 2005 18:50:42 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id C8C3E51A10; Sun, 6 Feb 2005 21:50:38 -0500 (EST) In-Reply-To: References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Sun, 6 Feb 2005 18:50:35 -0800 To: "Roy T.Fielding" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote: > On Feb 5, 2005, at 9:48 AM, Mark Nottingham wrote: >> What does that mean? SOAP is a "Must Ignore format," but it also has >> a way of saying that you have to understand a particular extension; >> as I said before, this is one of the big problems with HTTP. >> mustUnderstand should be used sparingly, but sometimes it's >> necessary. > > The problem with that statement (about HTTP) is that absence of a > must-understand in HTTP is not one of its big problems. Yes, I know > lots of people have talked about it as a limiting factor in the syntax > of HTTP, but to call it an actual problem would say that it prevented > some good from being accomplished. It arguably tipped some people towards SOAP when HTTP would have been adequate. That's not a prevention of good, but we've already seen enough fragmentation in the syndication world. > Things that a syndication format might want to make mandatory are > copyright controls and micropayments, but both have been shown in > practice to require either a willingness on the part of the recipient > to accept that specific restriction (i.e., human intervention and > understanding) or forceful requirement by the sender (i.e., > encryption). In both cases, agreements have to be established with the > user in advance, before they even receive the content, and thus do not > need a "must understand" feature. I don't think mU is intended for such things; rather, the case for mU could be characterised as extensions that change the operation of the protocol in a manner that renders it useless or misleading to try to use the feed if you don't know what to do with the extension. It's advisory. > In fact, "must understand" has no value in a network-based application > except as positive guidance for intermediaries, which is something > that can still be accomplished under mustIgnore with a bit of > old-fashioned advocacy. So, if I can restate your position, you're saying that you don't dispute that understanding some extensions may be required, but that it isn't necessary to make that visible to the processor, because it'll be co-ordinated beforehand (e.g., through market forces, out-of-band-communication), correct? I don't disagree that advocacy, standardisation and marketshare have an influence on the adoption of extensions that's impossible to underestimate. mU is not meant to replace this; rather, it's intended to make the introduction of non-compatible extensions a bit easier, by making what the processor needs to support more obvious when it actually sees the feed. Many people have been saying that mU will be misused, and therefore they don't think it should be included. I don't think this will be the case; it's up to an individual feed author as to whether to use it, and they can easily observe its effects in Atom processors, so they'll be able to make an informed decision as to whether it's necessary. And, as its been said, some people will undoubtedly ignore the mU flag; that's OK too, as long as they know what responsibility they're taking on (i.e., they've opened up the box and have voided the warranty). -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Sun Feb 6 22:10:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24409 for ; Sun, 6 Feb 2005 22:10:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1733Asp019606; Sun, 6 Feb 2005 19:03:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1733A8U019605; Sun, 6 Feb 2005 19:03:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxout-03.mxes.net (mxout-03.mxes.net [205.237.194.34]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17338fH019598 for ; Sun, 6 Feb 2005 19:03:09 -0800 (PST) (envelope-from mnot@mnot.net) Received: from [172.16.1.2] (adsl-67-119-69-243.dsl.sntc01.pacbell.net [67.119.69.243]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id A870651A25; Sun, 6 Feb 2005 22:03:06 -0500 (EST) In-Reply-To: References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8afc3e5b73daae3108af7e9513d5210a@mnot.net> Content-Transfer-Encoding: 7bit Cc: Dan Brickley , Atom Syntax , John Panzer , Eric Scheid X-Image-Url: http://www.mnot.net/personal/MarkNottingham.jpg From: Mark Nottingham X-Face: }I;hHtiZ43-RK8s{or'?iELJ;!_Mt2|\hW'VcAn*UR#@;4p5@s},~+i=>p})B"gMK%m,`?|Cy>=P/om{?_\aOaPaDMK)TkU_b3]A85YU?A 3iYcf9##+Qu~e(m6w=ot[yfp1G)WXBYGcTM{!EWIB2n/%E@5PjJ_GXq(b2Fq0|#uL{ Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Sun, 6 Feb 2005 19:03:05 -0800 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is why I prefer "snapshot" to "feed"; the latter doesn't convey what an Atom Feed Document really is, and leads to just this kind of confusion. Another direction to go in would be to add metadata (probably in the head) that says what kind of feed it is; e.g., "an archive," "a snapshot of the last three days," "a snapshot since last Monday," "a snapshot of the last 10 entries." This might add some complexity, but a stub that just allowed you to differentiate between archive and snapshot might be useful, and could be extended upon in the future, while remaining pretty simple now. On Feb 6, 2005, at 3:09 PM, Roy T. Fielding wrote: > > On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote: >> * John Panzer [2005-02-06 13:58-0800] >> >>> Since an entry is identified uniquely by its atom:id (though it can >>> have >>> different states at different times); >> >> As I understand the Web, the "REST" concepts that underpin HTTP >> are quite happy with their being multiple representations of >> the selfsame resource *at the time*. > > Also at multiple times. > > Yes, it's all about time, but also about resources. The entry is > a resource, and that resource may have multiple representations at > a single time (atom, rss1, rss2) and also over different times. > A resource has a single state at one point in time, but may have > different states over time (in some case they must have different > states over time because that is the essence of what makes them > a resource, just as a clock is expected to have different state). > URIs identify resources, not necessarily singular states. > > Feeds are sliding window resources, but their representations > do not slide -- they are fixed at a given point in time. If it is > reasonable to say that, at any single point in time, only one > representation of a given entry can appear in the feed's > representation, then the only valid representation of a feed > is one that does not contain any duplicate entry id's. > > An atom:feed document is a representation of a single feed > resource at a single point in time. > > Aggregators do not consume feed resources -- they consume an > iterative set of overlapping feed representations. Aggregators > are therefore required by Atom to only include the "latest" > version of an entry within their own resource representations. > > I believe that these requirements reflect the desires of most > of the participants in this working group, so it seems to me > that the question has been answered. > > > Cheers, > > Roy T. Fielding > Chief Scientist, Day Software > > > -- Mark Nottingham http://www.mnot.net/ From owner-atom-syntax@mail.imc.org Mon Feb 7 04:15:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08574 for ; Mon, 7 Feb 2005 04:15:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1794kZm013001; Mon, 7 Feb 2005 01:04:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1794k94012999; Mon, 7 Feb 2005 01:04:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1794iZc012895 for ; Mon, 7 Feb 2005 01:04:45 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050207090425.UTSK20856.mta10-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com> for ; Mon, 7 Feb 2005 09:04:25 +0000 Received: from cpc3-stke1-5-0-cust2.bagu.cable.ntl.com ([82.11.128.2]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050207090424.MVQC3760.aamta02-winn.mailhost.ntl.com@cpc3-stke1-5-0-cust2.bagu.cable.ntl.com> for ; Mon, 7 Feb 2005 09:04:24 +0000 Date: Mon, 7 Feb 2005 08:29:54 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1301955820.20050207082954@djpowell.net> To: atom-syntax@imc.org Subject: Posted PaceLangSpecific MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I've posted PaceLangSpecific. It allows the use of xml:lang, but clarifies which properties are language specific. == Abstract == Allow xml:lang anywhere, but restrict its effects to specific elements so that it is clear when implementations must preserve the language context. == Status == Open Author: DavidPowell == Rationale == xml:lang can appear anywhere and specifies a language for all children of its containing element. This is simple enough in the context of an XML document, but in the context of any other model, language tags need to be explicitly preserved for every property of each entry and feed. Many Atom implementations will use RDBMs or object-oriented implementations, rather than XML DOMs to model and store atom content internally. In a RDBMs model, each language sensitive field will require an extra database column. It is clear that some fields, such as atom:updated, are not language dependant, while others such as atom:content are. Some fields are grey areas. This proposal improves interoperability by ensuring that xml:lang is processed consistently by different implementations. It improves efficiency by allowing implementations to safely discard the language context for non-language specific fields. == Proposal == In section 2, replace: {{{ Any element in an Atom Document MAY have an xml:lang attribute, whose content indicates the natural language of the element's content. Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}} with: {{{ Any element in an Atom Document MAY have an xml:lang attribute, whose content sets the language content for the element and its children. The language context is only significant for the language sensitive constructs, which are indicated in this specification. Implementations MUST preserve the language context of language sensitive constructs. Requirements regarding the content and interpretation of xml:lang are specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}} In section 3.1, add the sentence: {{{ Except for the "type" attribute, the content of Text constructs is language sensitive. }}} In section 3.2.1, add the sentence: {{{ The content of atom:name is language sensitive. }}} In section 4.6.5, add the sentence: {{{ The content of the "title" attribute is language sensitive. }}} In section 4.13.3, add the sentence: {{{ The content of the "label" attribute is language sensitive. }}} In section 4.15, add the sentence: {{{ Except for the "type" and "src" attributes, the content of atom:content is language sensitive. }}} == Impacts == Depending on which extension paces are accepted, a statement on the default language sensitivity of extension elements will need to be made. -- Dave From owner-atom-syntax@mail.imc.org Mon Feb 7 04:16:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08654 for ; Mon, 7 Feb 2005 04:16:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1794k8t013007; Mon, 7 Feb 2005 01:04:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1794kW9013006; Mon, 7 Feb 2005 01:04:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta10-winn.mailhost.ntl.com (smtpout18.mailhost.ntl.com [212.250.162.18]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1794imk012926 for ; Mon, 7 Feb 2005 01:04:45 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta02-winn.mailhost.ntl.com ([212.250.162.8]) by mta10-winn.mailhost.ntl.com with ESMTP id <20050207090435.UUNF20856.mta10-winn.mailhost.ntl.com@aamta02-winn.mailhost.ntl.com>; Mon, 7 Feb 2005 09:04:35 +0000 Received: from cpc3-stke1-5-0-cust2.bagu.cable.ntl.com ([82.11.128.2]) by aamta02-winn.mailhost.ntl.com with ESMTP id <20050207090435.MWDR3760.aamta02-winn.mailhost.ntl.com@cpc3-stke1-5-0-cust2.bagu.cable.ntl.com>; Mon, 7 Feb 2005 09:04:35 +0000 Date: Mon, 7 Feb 2005 09:04:18 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <879383564.20050207090418@djpowell.net> To: Eric Scheid CC: Atom Syntax Subject: Re: Call for final Paces for consideration: deadline imminent In-Reply-To: <41FE0DEE0000490F@gps07-c1107.vodafone.net> References: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sunday, February 6, 2005, 3:10:23 AM, you wrote: > On 6/2/05 4:27 AM, "David Powell" wrote: >> Although we could keep the model we have (let's call it the 'mutable entries' >> model), it isn’t clear on a number of issues. Eg, if an old version of an >> entry has some property that isn’t present in a newer version, does that >> property still apply to the new instance? The answer is presumably 'no' but >> it isn't obvious from the spec. Under a 'multiple instances' model, it would >> be implicit. > +1 > now go write a pace, and quickly > e. My plan was to take the Atom Concepts section of the document, add "Entry Instance" to it, and do a bit of find/replacing to make it clear that properties are properties of the instance and id is the id of the Entry itself. Unfortunately there is no Atom Concepts section, so I have not had time to do this. Currently the only definition of what an entry or feed is in the informal introduction in the first couple of sentences of the specification. I think we should to insert an "Atom Concepts" section before the current section 2 so that we can properly explain the important terms in Atom before we can talk about how to represent them in the format. Can we fix this as an editorial issue? There is enough confusion about entries and ids amongst the working group, nevermind the readers. -- Dave From owner-atom-syntax@mail.imc.org Mon Feb 7 04:16:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08707 for ; Mon, 7 Feb 2005 04:16:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j178vfTi010452; Mon, 7 Feb 2005 00:57:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j178vfNU010451; Mon, 7 Feb 2005 00:57:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr2.netsolmail.com (omr2.netsolmail.com [216.168.230.163]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j178vfbd010428 for ; Mon, 7 Feb 2005 00:57:41 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr2.netsolmail.com (8.12.10/8.12.10) with ESMTP id j178tDHQ026123; Mon, 7 Feb 2005 03:57:33 -0500 (EST) Received: from boblaptop (68-174-167-137.nyc.rr.com [68.174.167.137]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COG56332; Mon, 7 Feb 2005 03:53:23 -0500 (EST) Message-Id: <200502070853.COG56332@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Mark Nottingham'" , "'Roy T.Fielding'" Cc: "'Atom Syntax'" Subject: RE: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Mon, 7 Feb 2005 03:53:21 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUMwiOTQxRWSlV1T8mJnDctT4Z8/QALwWCA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Nottingham wrote: > some people will undoubtedly ignore the mU flag; that's > OK too, as long as they know what responsibility they're taking on > (i.e., they've opened up the box and have voided the warranty). How should an intermediary like PubSub, Google, Feedster, Technorati, etc. respond when a mU element is found in an entry? Should it be ignored and the entry forwarded to the subscriber or included in a search results feed? Or, should all entries with mU elements be discarded by intermediaries? How can the intermediary know if this is a reasonable thing to do? Isn't it possible that the mU element might require something in the feed that is external to the entry that matched the query filter? Or, is it possible that an mU element could have an effect on the processing of more than one entry? Thus, if an entry that contained such an element was inserted into a stream of other entries from other feeds, might this mU element cause "damage" to the other entries? Should there be two types of mU? (i.e. intermediary-must-understand and client-must-understand) If mU is specific to processor type, should we provide a more general method of specifying who must-understand? If so, what is the extensibility model for the definition of mU scope? More questions can be delivered on demand. In any case, it seems like there isn't time to finish this discussion. bob wyman From owner-atom-syntax@mail.imc.org Mon Feb 7 04:48:17 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10784 for ; Mon, 7 Feb 2005 04:48:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j179gCnv027227; Mon, 7 Feb 2005 01:42:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j179gCua027226; Mon, 7 Feb 2005 01:42:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail09.svc.cra.dublin.eircom.net (mail09.svc.cra.dublin.eircom.net [159.134.118.25]) by above.proper.com (8.12.11/8.12.9) with SMTP id j179gAJ4027176 for ; Mon, 7 Feb 2005 01:42:11 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 27597 messnum 2006216 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 09:42:03 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail09.svc.cra.dublin.eircom.net (qp 27597) with SMTP; 7 Feb 2005 09:42:03 -0000 Message-ID: <420737E5.9010800@dehora.net> Date: Mon, 07 Feb 2005 09:41:57 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: bob@wyman.us CC: "'Mark Nottingham'" , "'Roy T.Fielding'" , "'Atom Syntax'" Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] References: <200502070853.COG56332@ms8.netsolmail.com> In-Reply-To: <200502070853.COG56332@ms8.netsolmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Bob Wyman wrote: > Mark Nottingham wrote: > >>some people will undoubtedly ignore the mU flag; that's >>OK too, as long as they know what responsibility they're taking on >>(i.e., they've opened up the box and have voided the warranty). > > How should an intermediary like PubSub, Google, Feedster, > Technorati, etc. respond when a mU element is found in an entry? Here's the thing; almost any mU use-case I can think of involves a point-to-point communication between two parties where the sender is directly addressing the recipient or a relatively small set of recipients. It doesn't make sense in a pseudo-broadcast environment, which seems to be most RSS served up today. That includes aggregators. It's the difference between "I'm sending this document and you must understand these data" and "I'm putting this document on the web and everyone must understand these data". I doubt the latter is viable. cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 05:49:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14996 for ; Mon, 7 Feb 2005 05:49:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17AdKVF048800; Mon, 7 Feb 2005 02:39:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17AdKia048799; Mon, 7 Feb 2005 02:39:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17AdBNN048687 for ; Mon, 7 Feb 2005 02:39:11 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 26520 invoked by uid 17064); 7 Feb 2005 10:39:02 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 10:39:02 -0000 In-Reply-To: References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Dan Brickley , Atom Syntax , Eric Scheid , John Panzer , Tim Bray , bloged From: Henry Story Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 11:38:37 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Feb 2005, at 00:09, Roy T. Fielding wrote: > On Feb 6, 2005, at 2:24 PM, Dan Brickley wrote: >> * John Panzer [2005-02-06 13:58-0800] >> >>> Since an entry is identified uniquely by its atom:id (though it can >>> have >>> different states at different times); >> >> As I understand the Web, the "REST" concepts that underpin HTTP >> are quite happy with their being multiple representations of >> the selfsame resource *at the time*. > > Also at multiple times. > > Yes, it's all about time, but also about resources. The entry is > a resource, and that resource may have multiple representations at > a single time (atom, rss1, rss2) and also over different times. > A resource has a single state at one point in time, but may have > different states over time (in some case they must have different > states over time because that is the essence of what makes them > a resource, just as a clock is expected to have different state). > URIs identify resources, not necessarily singular states. It is about resources, but the question is what the id resource identifies. There are two things the id resource could identify: a- the uri of the entry (rdf:about) b- a uri related to the entry by the id relation (rdf:resource) I find interpretation b to be the most powerful one, because it allows us to narrow the disagreement between both factions down to the properties of the id relation. Here is how I model in rdf arrow notation the atom example [1]: _entry |--title-> "Atom Powered Robots Run Amok" |--link--> |--id----> |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime The differences this group has as to the interpretation of the id relation can be explained as follows: -those that like Bob Wyman and me-currently, believe that id is just a functional relation. Call this the [Functional Id] theory. -others like Roy Fielding and me-when-I-first-thought-of-the-issue, think of id as an equivalence relation (which I think just means that the relation is functional, symmetric and transitive). Call this the [Equivalence Id] theory. Under the [Equivalence ID] theory, the above graph has the following graph as consequence. |--title-> "Atom Powered Robots Run Amok" |--link--> |-update-> "2003-12-13T18:30:02Z"^^xsd:dateTime The above conclusion cannot be drawn from the [Functional ID] theory. Note that both theories: - are expressed in terms of resources - could easily be compatible: it would just require distinguishing the [Equivalence ID] relation and the [Functional ID] relation by naming them differently. Let us do so now: [Functional ID] -> funcId [Equivalence ID] -> equivId > Feeds are sliding window resources, but their representations > do not slide -- they are fixed at a given point in time. Yes, I agree. But the time component is only as important as you say if you emphasize http URIs for your id. But that will come out more clearly below. > If it is > reasonable to say that, at any single point in time, only one > representation of a given entry can appear in the feed's > representation, then the only valid representation of a feed > is one that does not contain any duplicate entry id's. This is true only if you have the [Equivalence ID] interpretation of the id relation. (Ie you think of id as equivId.) To give a more concrete example let us use the well understood http URIs for our ids, and let us disambiguate the two id types. _entry |--title---> "Atom Powered Robots Run Amok" |--link--> |--funcId--> |--equivId-> |-update---> "2003-12-13T18:30:02Z"^^xsd:dateTime The file system layout would be something like the following (taking root at 2005/02/07 to save space) entry03 <-- a directory resource pointed to by the funcId uri entry03/v1 <-- a directory resource for the previous entry version entry03/v1/entry/xml <-- the first entry version of the xml entry03/v1/entry.html <-- the second entry version in html form entry03/v2 <-- a directory resource pointed to by the equivId uri entry03/v2/entry.xml <-- the second entry version in xml format entry03/v2/entry.html <-- the first entry version in html format With the above file system layout it would therefore be completely feasible to have a feed that would correctly state at a precise time the following: Atom-Powered Robots Run Amok http://bblfish.net/2005/02/07/entry03/ http://bblfish.net/2005/02/07/entry03/v1/ 2003-12-13T18:30:02Z Atom-Powered Robots Run Amok http://bblfish.net/2005/02/07/entry03/ http://bblfish.net/2005/02/07/entry03/v2/ 2003-12-13T18:30:02Z There are indeed two versions of the entry at one point in time with the same funcIds specified above, but as you also rightly point out two *different* equivIds. > An atom:feed document is a representation of a single feed > resource at a single point in time. ok. > > Aggregators do not consume feed resources -- they consume an > iterative set of overlapping feed representations. Aggregators > are therefore required by Atom to only include the "latest" > version of an entry within their own resource representations. Only if you reduce the toolset available by requiring no one use a funcId relation. Otherwise it is quite possible to have multiple versions of an entry in the same feed as I clearly showed above. > I believe that these requirements reflect the desires of most > of the participants in this working group, so it seems to me > that the question has been answered. Now is the time to question this statement. I would like to start by an obvious objections someone is bound to make to the example file system layout I described above, namely that it is much too complicated for most end users [2], and that most blog layouts will only have a simple, non versioned, layout. Something more like this: 2005/02/07/entry03 <-- a directory resource for the entry 2005/02/07/entry03/entry.xml <-- the xml version of the entry 2005/02/07/entry03/entry.html <-- the html version of the entry 2005/02/07/entry04/ <-- a directory resource for another entry 2005/02/07/entry04/entry.xml 2005/02/07/entry04/entry.html If the id were to point to the resource, as one would be tempted to do, then this would clearly imply a [Equivalence ID] interpretation of id, and so of course having two differing entries with the same id in a feed document would be saying something contradictory and false. This is an obvious intuition, that I myself followed for a long time. But of course this does not take into account this groups very long and convoluted discussions concerning the Identity Constructs, and the discussions about what an id really should be: should it just be a String? A String that can be seen to be a URI, but should not be thought to be one? ... Many people have vocally tried to limit the URIs allowed for an id to the set of URIs that are *not* URLs. In fact the default example given in the spec does not use a URL but some 'vemmi' URI. Non URL URIs such as 'vemmi' URIs are needed to create a non temporal identity of an entry that allows even simple file system layouts such as the one just shown to be given an id that makes sense in the [Functional ID] interpretation. Here is how the feed can be composed of such entries without this raising any special problem. ... Atom-Powered Robots Really Run Amok vemmi://example.org/2003/32397 2005-02-07T09:30:02Z Atom-Powered Robots Run Amok vemmi://example.org/2003/32397 2003-12-13T18:30:02Z Since entries here described are just versions of the atemporal entry. So without trying to work out or guess what the changing desires of this working group are (I myself moved from one side to the other on this issue), I think we should rather try to decide on by weighing as Bob Wyman did, the advantages of each. And if this still does not allow one to choose one should perhaps just allow both. Henry Story Ps. If you do read this please send me a postcard, or short e-mail :-) > > Cheers, > > Roy T. Fielding > Chief Scientist, Day Software [1] _entry is a blank node as indicated by the leading '_' The graph is a simplified version of a full model for purposed of focusing on the current problem The atom example is the one available here: or here [2] though I wonder really how much weight arguments like this should have on IETF (Internet *Engineering* Task Force) groups, where we are already in the process of writing a huge spec, that requires understanding if HTTP, XML etc, none of which are that simple... > From owner-atom-syntax@mail.imc.org Mon Feb 7 06:45:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18758 for ; Mon, 7 Feb 2005 06:45:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17BaOaJ070864; Mon, 7 Feb 2005 03:36:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17BaOug070863; Mon, 7 Feb 2005 03:36:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17BaN5L070817 for ; Mon, 7 Feb 2005 03:36:23 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 96566 messnum 3869956 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 11:36:17 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 96566) with SMTP; 7 Feb 2005 11:36:17 -0000 Message-ID: <420752AC.6040805@dehora.net> Date: Mon, 07 Feb 2005 11:36:12 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: PaceJoinSectionSixAndTen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit http://www.intertwingly.net/wiki/pie/PaceJoinSectionSixAndTen == Abstract == Move everything security related into section 10 and drop section 6. Author: BillDehora == Status == Open == Rationale == * We don't need 2 security sections. * The reader will have one place to go re security. == Proposal == 1. Place the current section 6 paragraphs in draft05 under section 10. 1. Call section 10. 'Atom Security Considerations' == Impacts == Format section layout post draft05. == Notes == From owner-atom-syntax@mail.imc.org Mon Feb 7 07:23:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21580 for ; Mon, 7 Feb 2005 07:23:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CDLG6084729; Mon, 7 Feb 2005 04:13:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17CDLK0084727; Mon, 7 Feb 2005 04:13:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao07.cox.net (fed1rmmtao07.cox.net [68.230.241.32]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CDGwq084662 for ; Mon, 7 Feb 2005 04:13:20 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao07.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050207121310.LSSS1747.fed1rmmtao07.cox.net@[192.168.0.100]>; Mon, 7 Feb 2005 07:13:10 -0500 In-Reply-To: <200502070242.COE68341@ms8.netsolmail.com> References: <200502070242.COE68341@ms8.netsolmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <228ad371b6591902589e07f3b6689b49@gbiv.com> Content-Transfer-Encoding: 7bit Cc: "'Atom Syntax'" From: "Roy T. Fielding" Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 04:13:10 -0800 To: X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote: > Roy T. Fielding wrote: >> Aggregators do not consume feed resources -- they consume an >> iterative set of overlapping feed representations. > This is only true of pull based aggregators that poll for feeds. > None of the aggregators that I use are polling based. I use the PubSub > Sidebars and the Gush aggregator built by 2entwine.com. These > aggregators > consume streams of entries that are pushed to them using the "Atom over > HTTP" protocol. No, they consume feed representations of length=1, which contains an entry representation. They are neither streams nor entries, and if we stop confusing the messages received with the rather abstract notion of what the author considers to be their entry, then it is much easier to understand what the id tells the recipient. This is not specific to the transfer protocol. It is an aspect of message passing architectures. Most network-based systems build tremendously complex synchronization and update mechanisms in an attempt to make message passing match what an ideal world would consider reality. Unfortunately for them, the theory of relativity is just as applicable to software as it is to us. HTTP (or at least the use of HTTP based on REST) changes the perspective by acknowledging that messages are not the same as what is identified. It seems a little odd, at first, but it makes a huge difference because clients stop assuming that they have a complete understanding, servers supply more explicit information about what they do send, and the overall system becomes less brittle during failures. However, HTTP only tries to match what is already true of message passing -- it does not make the rules. Regardless of the protocol used to receive an atom feed, the only things that will actually be received are representations. Computers can't transfer a temporal mapping that has yet to be defined. ....Roy From owner-atom-syntax@mail.imc.org Mon Feb 7 07:42:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22700 for ; Mon, 7 Feb 2005 07:42:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CXdHY092180; Mon, 7 Feb 2005 04:33:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17CXd7q092179; Mon, 7 Feb 2005 04:33:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from fed1rmmtao04.cox.net (fed1rmmtao04.cox.net [68.230.241.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CXcDb092144 for ; Mon, 7 Feb 2005 04:33:38 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from [192.168.0.100] (really [68.4.71.218]) by fed1rmmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-117-20041022) with ESMTP id <20050207123333.LAHO19250.fed1rmmtao04.cox.net@[192.168.0.100]>; Mon, 7 Feb 2005 07:33:33 -0500 In-Reply-To: <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5ed187a16ab4416828c4ce7248357447@gbiv.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: "Roy T. Fielding" Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 04:33:33 -0800 To: Henry Story X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 2:38 AM, Henry Story wrote: > On 7 Feb 2005, at 00:09, Roy T. Fielding wrote: >> Feeds are sliding window resources, but their representations >> do not slide -- they are fixed at a given point in time. > > Yes, I agree. But the time component is only as important as you > say if you emphasize http URIs for your id. But that will come out > more clearly below. No, Henry, the time component comes from a person's ability to change an entry over time. The URI is only relevant in the sense that it has to allow a variable mapping over time, which is true of all URIs that are in actual use today [not including some of the fixed-content or fixed-time URI schemes that have been proposed but not actually deployed]. >> If it is >> reasonable to say that, at any single point in time, only one >> representation of a given entry can appear in the feed's >> representation, then the only valid representation of a feed >> is one that does not contain any duplicate entry id's. > > This is true only if you have the [Equivalence ID] interpretation > of the id relation. (Ie you think of id as equivId.) Yes, and to make myself perfectly clear, that means functional ID, as you call it, would conflict with the design of Atom and any reasonable design of a system wherein the things being identified are allowed to be updated over time. So, please, stop trying to make a real system fit an artificial model of graph theory that isn't even capable of describing the Web. Fix your model instead. ....Roy From owner-atom-syntax@mail.imc.org Mon Feb 7 07:43:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22723 for ; Mon, 7 Feb 2005 07:43:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CYuD0092667; Mon, 7 Feb 2005 04:34:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17CYuWH092666; Mon, 7 Feb 2005 04:34:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17CYt5K092648 for ; Mon, 7 Feb 2005 04:34:55 -0800 (PST) (envelope-from danbri@w3.org) Received: by homer.w3.org (Postfix, from userid 13522) id 103E24F263; Mon, 7 Feb 2005 07:34:53 -0500 (EST) Date: Mon, 7 Feb 2005 07:34:53 -0500 From: Dan Brickley To: "Roy T. Fielding" Cc: bob@wyman.us, "'Atom Syntax'" Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Message-ID: <20050207123452.GK24468@homer.w3.org> References: <200502070242.COE68341@ms8.netsolmail.com> <228ad371b6591902589e07f3b6689b49@gbiv.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <228ad371b6591902589e07f3b6689b49@gbiv.com> X-FOAF: http://danbri.org/foaf.rdf User-Agent: Mutt/1.5.6+20040907i Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Roy T. Fielding [2005-02-07 04:13-0800] > > On Feb 6, 2005, at 6:42 PM, Bob Wyman wrote: > >Roy T. Fielding wrote: > >>Aggregators do not consume feed resources -- they consume an > >>iterative set of overlapping feed representations. > > This is only true of pull based aggregators that poll for feeds. > >None of the aggregators that I use are polling based. I use the PubSub > >Sidebars and the Gush aggregator built by 2entwine.com. These > >aggregators > >consume streams of entries that are pushed to them using the "Atom over > >HTTP" protocol. > > No, they consume feed representations of length=1, which contains > an entry representation. They are neither streams nor entries, and > if we stop confusing the messages received with the rather abstract > notion of what the author considers to be their entry, then it is > much easier to understand what the id tells the recipient. +1; we're exchanging representations (or maybe 'descriptions') not the things themselves. This becomes a lot clearer when we think about feed markup that describes people, places, products etc. inside the entry/item descriptions. > This is not specific to the transfer protocol. It is an aspect > of message passing architectures. Most network-based systems > build tremendously complex synchronization and update mechanisms > in an attempt to make message passing match what an ideal > world would consider reality. Unfortunately for them, the theory > of relativity is just as applicable to software as it is to us. > > HTTP (or at least the use of HTTP based on REST) changes the > perspective by acknowledging that messages are not the same > as what is identified. It seems a little odd, at first, > but it makes a huge difference because clients stop assuming > that they have a complete understanding, servers supply more > explicit information about what they do send, and the overall > system becomes less brittle during failures. However, HTTP > only tries to match what is already true of message passing -- > it does not make the rules. > > Regardless of the protocol used to receive an atom feed, the > only things that will actually be received are representations. > Computers can't transfer a temporal mapping that has yet to > be defined. This thread is getting to the core of the different styles of thinking about RSS and Atom feeds. It is pretty widespread for people to think about RSS/Atom feeds in non-RESTy terms, ie. that the chunks of markup are 'the things themselves, being transported around the net'. From the RDF side of things, it is more natural to take the other view and see feeds as documents that describe things (such as themselves, items/entries, and the -- often realworld -- things those entries are about...). I am glad to see this discussion happening Dan From owner-atom-syntax@mail.imc.org Mon Feb 7 08:27:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27522 for ; Mon, 7 Feb 2005 08:27:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DCDR1006776; Mon, 7 Feb 2005 05:12:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17DCDFv006775; Mon, 7 Feb 2005 05:12:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from homer.w3.org (homer.w3.org [128.30.52.30]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DCD8E006765 for ; Mon, 7 Feb 2005 05:12:13 -0800 (PST) (envelope-from duerst@w3.org) Received: from EBOSHIIWA.w3.org (homer.w3.org [128.30.52.30]) by homer.w3.org (Postfix) with ESMTP id 286254F3DE; Mon, 7 Feb 2005 08:12:10 -0500 (EST) Message-Id: <6.0.0.20.2.20050207184243.100f5958@localhost> X-Sender: duerst@localhost X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Mon, 07 Feb 2005 18:44:11 +0900 To: David Powell , atom-syntax@imc.org From: Martin Duerst Subject: Re: Posted PaceLangSpecific In-Reply-To: <1301955820.20050207082954@djpowell.net> References: <1301955820.20050207082954@djpowell.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello David, Many thanks for writing this up. I thought about writing it up myself, but I'm glad I didn't start before I saw yours. I haven't yet looked at the details, but I'm definitely +1 on the general idea. Regards, Martin. At 17:29 05/02/07, David Powell wrote: > >I've posted PaceLangSpecific. It allows the use of xml:lang, but >clarifies which properties are language specific. > > > >== Abstract == > >Allow xml:lang anywhere, but restrict its effects to specific elements >so that it is clear when implementations must preserve the language >context. > >== Status == > >Open > >Author: DavidPowell > > >== Rationale == > >xml:lang can appear anywhere and specifies a language for all children >of its containing element. This is simple enough in the context of an >XML document, but in the context of any other model, language tags >need to be explicitly preserved for every property of each entry and >feed. > >Many Atom implementations will use RDBMs or object-oriented >implementations, rather than XML DOMs to model and store atom content >internally. In a RDBMs model, each language sensitive field will >require an extra database column. It is clear that some fields, such >as atom:updated, are not language dependant, while others such as >atom:content are. Some fields are grey areas. > >This proposal improves interoperability by ensuring that xml:lang is >processed consistently by different implementations. It improves >efficiency by allowing implementations to safely discard the language >context for non-language specific fields. > >== Proposal == > >In section 2, replace: > >{{{ Any element in an Atom Document MAY have an xml:lang attribute, >whose content indicates the natural language of the element's content. >Requirements regarding the content and interpretation of xml:lang are >specified in XML 1.0 [W3C.REC-xml-20040204] Section 2.12. }}} > >with: > >{{{ Any element in an Atom Document MAY have an xml:lang attribute, >whose content sets the language content for the element and its >children. The language context is only significant for the language >sensitive constructs, which are indicated in this specification. >Implementations MUST preserve the language context of language >sensitive constructs. Requirements regarding the content and >interpretation of xml:lang are specified in XML 1.0 >[W3C.REC-xml-20040204] Section 2.12. }}} > >In section 3.1, add the sentence: > >{{{ Except for the "type" attribute, the content of Text constructs is >language sensitive. }}} > >In section 3.2.1, add the sentence: > >{{{ The content of atom:name is language sensitive. }}} > >In section 4.6.5, add the sentence: > >{{{ The content of the "title" attribute is language sensitive. }}} > >In section 4.13.3, add the sentence: > >{{{ The content of the "label" attribute is language sensitive. }}} > >In section 4.15, add the sentence: > >{{{ Except for the "type" and "src" attributes, the content of >atom:content is language sensitive. }}} > > > >== Impacts == > >Depending on which extension paces are accepted, a statement on the >default language sensitivity of extension elements will need to be >made. > > > >-- >Dave From owner-atom-syntax@mail.imc.org Mon Feb 7 08:28:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27668 for ; Mon, 7 Feb 2005 08:28:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DFp0Q008438; Mon, 7 Feb 2005 05:15:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17DFpHl008436; Mon, 7 Feb 2005 05:15:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DFoRd008429 for ; Mon, 7 Feb 2005 05:15:50 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 56700 invoked by uid 17064); 7 Feb 2005 13:15:49 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 13:15:49 -0000 In-Reply-To: <5ed187a16ab4416828c4ce7248357447@gbiv.com> References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> <5ed187a16ab4416828c4ce7248357447@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 14:15:25 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Feb 2005, at 13:33, Roy T. Fielding wrote: >>> If it is >>> reasonable to say that, at any single point in time, only one >>> representation of a given entry can appear in the feed's >>> representation, then the only valid representation of a feed >>> is one that does not contain any duplicate entry id's. >> >> This is true only if you have the [Equivalence ID] interpretation >> of the id relation. (Ie you think of id as equivId.) > > Yes, and to make myself perfectly clear, that means functional ID, > as you call it, would conflict with the design of Atom and any > reasonable design of a system wherein the things being identified > are allowed to be updated over time. I wonder if you read the rest of my message... I gave an example that did not conflict with a reasonable design. Here is a reasonable design of the files in a web site for an entry with versioning: entry03 <-- a directory resource pointed to by the funcId uri entry03/v1 <-- a directory resource for the previous entry version entry03/v1/entry.xml <-- the first entry version of the xml entry03/v1/entry.html <-- the second entry version in html form entry03/v2 <-- a directory resource pointed to by the equivId uri entry03/v2/entry.xml <-- the second entry version in xml format entry03/v2/entry.html <-- the first entry version in html format Here is a reasonable feed corresponding to the above file system layout of resources: Atom-Powered Robots Run Amok! http://bblfish.net/2005/02/07/entry03/ http://bblfish.net/2005/02/07/entry03/v1/ 2003-12-13T18:30:02Z Atom-Powered Robots Run Amok http://bblfish.net/2005/02/07/entry03/ http://bblfish.net/2005/02/07/entry03/v2/ 2003-12-13T18:30:02Z ((It seems to me that when blogging it is very good practice to keep the changes of one's entries available as above, since one's changing one's mind on an issue affects the pages and comments of other people pointing to your entry.)) Anyway, as you see I am agreeing with you that equivId will be different for each entry in a feed, though funcId is the same. There we have a feed that contains both notions. > So, please, stop trying to > make a real system fit an artificial model of graph theory that > isn't even capable of describing the Web. Fix your model instead. Do you have a good paper that proves your incredibly strong statement above? I would be happy to understand this position, as it would save me a lot of time. But I can't just take your word for it, as there are numerous people who don't seem to think the way you do, and in just as senior or more senior positions than your are. But perhaps I have missed some important development recently. (I am not being ironic here though it may sound like it. I really would like to understand more fully your position.) Henry Story From owner-atom-syntax@mail.imc.org Mon Feb 7 08:56:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00262 for ; Mon, 7 Feb 2005 08:56:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DeFP1015177; Mon, 7 Feb 2005 05:40:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17DeFtR015174; Mon, 7 Feb 2005 05:40:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DeFtF015159 for ; Mon, 7 Feb 2005 05:40:15 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 75307 invoked by uid 17064); 7 Feb 2005 13:40:15 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 13:40:15 -0000 In-Reply-To: References: <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> <5ed187a16ab4416828c4ce7248357447@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <699f455ad5c11afd7c36c467e34c96bd@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Henry Story Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 14:39:47 +0100 To: "Roy T. Fielding" X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Feb 2005, at 14:15, Henry Story wrote: > entry03 <-- a directory resource pointed to by the funcId uri > entry03/v1 <-- a directory resource for the previous entry version > entry03/v1/entry.xml <-- the first entry version of the xml > entry03/v1/entry.html <-- the second entry version in html form > entry03/v2 <-- a directory resource pointed to by the equivId uri > entry03/v2/entry.xml <-- the second entry version in xml format > entry03/v2/entry.html <-- the first entry version in html format Clearly there were a few typos in the above: entry03 <-- a directory resource pointed to by the funcId uri entry03/v1 <-- a directory resource for the previous entry version entry03/v1/entry.xml <-- the first entry version in atom xml entry03/v1/entry.html <-- the first entry version in html format entry03/v2 <-- a directory resource pointed to by the equivId uri entry03/v2/entry.xml <-- the second entry version in xml format entry03/v2/entry.html <-- the second entry version in html format From owner-atom-syntax@mail.imc.org Mon Feb 7 09:00:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00527 for ; Mon, 7 Feb 2005 09:00:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DdlAA015117; Mon, 7 Feb 2005 05:39:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17DdlpT015116; Mon, 7 Feb 2005 05:39:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mxsf40.cluster1.charter.net (mxsf40.cluster1.charter.net [209.225.28.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17DdklK015095 for ; Mon, 7 Feb 2005 05:39:46 -0800 (PST) (envelope-from ndw@nwalsh.com) Received: from mxip05.cluster1.charter.net (mxip05a.cluster1.charter.net [209.225.28.135]) by mxsf40.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id j17Dda7U024358 for ; Mon, 7 Feb 2005 08:39:36 -0500 Received: from cpe-68-112-239-32.ma.charter.com (HELO localhost) (68.112.239.32) by mxip05.cluster1.charter.net with ESMTP; 07 Feb 2005 08:39:35 -0500 X-Ironport-AV: i="3.88,183,1102309200"; d="scan'208"; a="597610883:sNHT31847634" Received: from ndw by localhost with local (Exim 4.44) id 1Cy96X-0001kS-EV for atom-syntax@imc.org; Mon, 07 Feb 2005 08:39:05 -0500 To: Atom Syntax Subject: Re: PaceDatesXSD References: From: Norman Walsh X-URL: http://nwalsh.com/ Date: Mon, 07 Feb 2005 08:38:55 -0500 In-Reply-To: (Eric Scheid's message of "Sun, 06 Feb 2005 15:01:15 +1100") Message-ID: <878y60sd5c.fsf@nwalsh.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable / Eric Scheid was heard to say: | On 6/2/05 9:38 AM, "Sam Ruby" wrote: | |> I am +1 on the regular expression limitation, |> believe that all dates that that conform to this limitation are valid |> RFC 3339 and xsd:dateTime values, and believe that it will interop with |> all of the existing XSD implementations. | | where "this" is the regex? that regex allows this totally bogus value | | 2005-13-34T25:65:96+00:65 | | there are test cases in the validator to check this, but those test cases | will no longer be supported by the spec and will thus be a bug in the | validator :-( I think the proposed constraint was (RFC 3339 or xsd:dateTime) and matching the regular expression. Be seeing you, norm =2D-=20 Norman Walsh | The only thing that makes life possible http://nwalsh.com/ | is permanent, intolerable uncertainty; | not knowing what comes next.--Ursula K. | LeGuin --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) iD8DBQBCB29vOyltUcwYWjsRAr4cAKCE2h20Yiq6OreNhuX87e8DxOyg1QCfcRCw w/jI9e1Q8s3EvzVWcRqehUc= =dX/0 -----END PGP SIGNATURE----- --=-=-=-- From owner-atom-syntax@mail.imc.org Mon Feb 7 10:33:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08727 for ; Mon, 7 Feb 2005 10:33:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17FIKS9025364; Mon, 7 Feb 2005 07:18:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17FIKCo025363; Mon, 7 Feb 2005 07:18:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17FIFJt025339 for ; Mon, 7 Feb 2005 07:18:19 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17FIBee009898; Mon, 7 Feb 2005 10:18:12 -0500 (EST) Message-ID: <42078693.1070907@intertwingly.net> Date: Mon, 07 Feb 2005 10:17:39 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norman Walsh CC: Atom Syntax Subject: Re: PaceDatesXSD References: <878y60sd5c.fsf@nwalsh.com> In-Reply-To: <878y60sd5c.fsf@nwalsh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Norman Walsh wrote: > / Eric Scheid was heard to say: > | On 6/2/05 9:38 AM, "Sam Ruby" wrote: > | > |> I am +1 on the regular expression limitation, > |> believe that all dates that that conform to this limitation are valid > |> RFC 3339 and xsd:dateTime values, and believe that it will interop with > |> all of the existing XSD implementations. > | > | where "this" is the regex? that regex allows this totally bogus value > | > | 2005-13-34T25:65:96+00:65 > | > | there are test cases in the validator to check this, but those test cases > | will no longer be supported by the spec and will thus be a bug in the > | validator :-( > > I think the proposed constraint was (RFC 3339 or xsd:dateTime) and > matching the regular expression. Let's take credit for all four requirements: regular expression, RFC 3339, xsd:dateTime, and w3cdtf. I don't know of any valid tool produced dates which would not conform to all four, so the requirement on the producer side should not be onerous. This would enable the widest range of readers. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 11:25:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13803 for ; Mon, 7 Feb 2005 11:25:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17G7mlS030433; Mon, 7 Feb 2005 08:07:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17G7m4Q030432; Mon, 7 Feb 2005 08:07:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17G7mVH030422 for ; Mon, 7 Feb 2005 08:07:48 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207160742014003imvce>; Mon, 7 Feb 2005 16:07:42 +0000 Date: Mon, 7 Feb 2005 09:07:41 -0700 Subject: Re: PaceArchiveDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <42064739.9060606@intertwingly.net> Message-Id: <64D90D42-7922-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, February 6, 2005, at 09:35 AM, Sam Ruby wrote: > Graham wrote: >> On 6 Feb 2005, at 3:39 pm, Sam Ruby wrote: >>> If you produce feeds that contain multiple entries with the same id, >>> there will be people who misunderstand such documents. >>> >>> I do believe that there needs to be some way to say "this is not a >>> feed, but an archive". >> Solution: >> A new atom:archive top level element with normal head and entry >> children. Difference is multiple instances of entries are allowed >> with the same id. Each is distinguished by a new atom:version date, >> that has no semantics other than determining which instance is the >> newest. Meanwhile, atom:version and multiple instances are explicitly >> banned from atom:feed. >> ? > > Works for me. > > Presumably, atom:entry elements can have at most one atom:version > child element. But, are atom:version elements be required in > atom:archives? > Okay, so we are punting on defining a way to archive the changing state of feed/head. Making something like the above semi-concrete: ... foo:bar/a ... foo:bar/a ... foo:bar/a ... ... ...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. @revision could go in instead of , or could be . We're at the deadline for paces. Someone who wants something like this should write one today. From owner-atom-syntax@mail.imc.org Mon Feb 7 11:57:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16243 for ; Mon, 7 Feb 2005 11:57:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GfiCx034588; Mon, 7 Feb 2005 08:41:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17GfiM9034587; Mon, 7 Feb 2005 08:41:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Gfhv1034564 for ; Mon, 7 Feb 2005 08:41:43 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17Gb0BZ028652; Mon, 7 Feb 2005 16:37:05 GMT In-Reply-To: <1301955820.20050207082954@djpowell.net> References: <1301955820.20050207082954@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71af7dc84c243e2de32bb47ebf8b751d@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Graham Subject: Re: Posted PaceLangSpecific Date: Mon, 7 Feb 2005 16:36:59 +0000 To: David Powell X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Feb 2005, at 8:29 am, David Powell wrote: > Implementations MUST preserve the language context of language > sensitive constructs. I have no idea what I'm being asked to do. Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 12:04:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17094 for ; Mon, 7 Feb 2005 12:04:41 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GnbSL035273; Mon, 7 Feb 2005 08:49:37 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17GnbpN035272; Mon, 7 Feb 2005 08:49:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GnZh3035259 for ; Mon, 7 Feb 2005 08:49:36 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <879383564.20050207090418@djpowell.net> References: <41FE0DEE0000490F@gps07-c1107.vodafone.net> (added by postmaster@vodafone.net> <879383564.20050207090418@djpowell.net> Date: Mon, 7 Feb 2005 08:45:38 -0800 To: Atom Syntax From: Paul Hoffman Subject: Editorial work Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:04 AM +0000 2/7/05, David Powell wrote: >Can we fix this as an editorial issue? There is enough confusion about >entries and ids amongst the working group, nevermind the readers. Yes and no. Yes if it is truly editorial with no technical side-effects; no if the changes have technical side-effects. For example, I see some people sliding the definition of "feed" towards something that doesn't match well the elements and attributes that we have made for feeds. Such a change would definitely be not OK. My proposal is that we add text copping to the fact that "feed" and "entry" and "id" were difficult for the WG to define precisely. Being honest is probably of more value to future implementers than us narrowing the definition down more than is warranted by the rest of the format document. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 12:06:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17331 for ; Mon, 7 Feb 2005 12:06:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Gnf8U035285; Mon, 7 Feb 2005 08:49:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17GnfZ9035284; Mon, 7 Feb 2005 08:49:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GnZh5035259; Mon, 7 Feb 2005 08:49:37 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <420752AC.6040805@dehora.net> References: <420752AC.6040805@dehora.net> Date: Mon, 7 Feb 2005 08:49:33 -0800 To: Bill de =?iso-8859-1?Q?h=D3ra?= , Atom Syntax From: Paul Hoffman Subject: Re: PaceJoinSectionSixAndTen Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -1. IETF documents have to have a "Security Considerations" section that describes general security issues. In no cases that I know of do they contain protocol specification. See RFC 3552 for more info. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 12:13:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17958 for ; Mon, 7 Feb 2005 12:13:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H0sRI036333; Mon, 7 Feb 2005 09:00:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17H0st8036332; Mon, 7 Feb 2005 09:00:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H0sSS036316 for ; Mon, 7 Feb 2005 09:00:54 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 27D69C9 for ; Mon, 7 Feb 2005 09:00:49 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17H0mLf000377 for ; Mon, 7 Feb 2005 09:00:48 -0800 (PST) Date: Mon, 07 Feb 2005 09:00:53 -0800 From: Walter Underwood To: Atom Syntax Subject: Re: PaceClarifyDateUpdated Message-ID: <22C7BB085BC2A25A264243F0@Wunders-Computer.local> In-Reply-To: <34b8342e11d8093498d6697ea717bfed@iki.fi> References: <957d7963cd94b91146eb98f51941519e@mac.com> <0f8c693589e085f5072fce6f90d0cc5f@iki.fi> <540e3732050206015616d5a93f@mail.gmail.com> <34b8342e11d8093498d6697ea717bfed@iki.fi> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 6, 2005 1:07:42 PM +0200 Henri Sivonen wrote: > > Yes. Also as a spec expectation--that is, how often is the "SHOULD NOT" expected > to be violated. Will the SHOULD NOT be violated so often that it dilutes the > meaning of all SHOULD NOTs? Roughly, a SHOULD or SHOULD NOT can be violated when the implementer understands and accepts the interoperability limitations they of that decision. So, the spec should (must?) explain what those are. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 12:14:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18024 for ; Mon, 7 Feb 2005 12:14:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GvfMs036000; Mon, 7 Feb 2005 08:57:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Gvf7r035999; Mon, 7 Feb 2005 08:57:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17GvfYm035981 for ; Mon, 7 Feb 2005 08:57:41 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 2731FC9 for ; Mon, 7 Feb 2005 08:57:34 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17GvWLf000312 for ; Mon, 7 Feb 2005 08:57:33 -0800 (PST) Date: Mon, 07 Feb 2005 08:57:37 -0800 From: Walter Underwood To: atom-syntax@imc.org Subject: RE: PaceArchiveDocument posted Message-ID: In-Reply-To: <200502060700.CNY83294@ms8.netsolmail.com> References: <200502060700.CNY83294@ms8.netsolmail.com> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 February 6, 2005 2:00:20 AM -0500 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. > > bob wyman > > > -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 12:22:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19104 for ; Mon, 7 Feb 2005 12:22:24 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H9RN0037515; Mon, 7 Feb 2005 09:09:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17H9RZQ037514; Mon, 7 Feb 2005 09:09:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail12.svc.cra.dublin.eircom.net (mail12.svc.cra.dublin.eircom.net [159.134.118.28]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17H9QL0037483 for ; Mon, 7 Feb 2005 09:09:27 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 41434 messnum 6477729 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 17:09:20 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail12.svc.cra.dublin.eircom.net (qp 41434) with SMTP; 7 Feb 2005 17:09:20 -0000 Message-ID: <4207A0BB.5090103@dehora.net> Date: Mon, 07 Feb 2005 17:09:15 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: PaceJoinSectionSixAndTen References: <420752AC.6040805@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > -1. IETF documents have to have a "Security Considerations" section that > describes general security issues. In no cases that I know of do they > contain protocol specification. See RFC 3552 for more info. Is that -1 to the proposed title or -1 to having one section? cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 12:22:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19191 for ; Mon, 7 Feb 2005 12:22:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H3m6q036941; Mon, 7 Feb 2005 09:03:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17H3mAI036940; Mon, 7 Feb 2005 09:03:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H3mQc036930 for ; Mon, 7 Feb 2005 09:03:48 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyCIW-0003Kq-CU; Mon, 07 Feb 2005 17:03:40 +0000 Message-ID: <42079F6B.6070409@franklinmint.fm> Date: Mon, 07 Feb 2005 12:03:39 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham CC: David Powell , atom-syntax@imc.org Subject: Re: Posted PaceLangSpecific References: <1301955820.20050207082954@djpowell.net> <71af7dc84c243e2de32bb47ebf8b751d@mac.com> In-Reply-To: <71af7dc84c243e2de32bb47ebf8b751d@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham wrote: > > On 7 Feb 2005, at 8:29 am, David Powell wrote: > >> Implementations MUST preserve the language context of language >> sensitive constructs. > > > I have no idea what I'm being asked to do. That sentence should be dropped, since we never ask implementations to preserve anything. David is trying to change the text on xml:lang, so that it doesn't allow meaningless stuff like ... Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 12:24:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19479 for ; Mon, 7 Feb 2005 12:24:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H6pJV037249; Mon, 7 Feb 2005 09:06:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17H6pW3037248; Mon, 7 Feb 2005 09:06:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17H6oqB037240 for ; Mon, 7 Feb 2005 09:06:50 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyCLW-0003Mv-Pq; Mon, 07 Feb 2005 17:06:46 +0000 Message-ID: <4207A026.30801@franklinmint.fm> Date: Mon, 07 Feb 2005 12:06:46 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 after all. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 12:30:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20101 for ; Mon, 7 Feb 2005 12:30:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HGNFr038145; Mon, 7 Feb 2005 09:16:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HGNwQ038144; Mon, 7 Feb 2005 09:16:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HGNY0038134 for ; Mon, 7 Feb 2005 09:16:23 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207171618014003h447e>; Mon, 7 Feb 2005 17:16:18 +0000 Date: Mon, 7 Feb 2005 10:16:17 -0700 Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200502070242.COE68341@ms8.netsolmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Sunday, February 6, 2005, at 07:42 PM, Bob Wyman wrote: > The whole "feed" business is simply an artifact of the > polling-based model of syndication. Interesting to hear the architecture for the model that most people use today be referred to as an "artifact". But yeah, to someone who doesn't used polling aggregators, it would seem so. > The polling oriented, feed-based model of syndication results in > significant waste of network bandwidth The "sliding window" view into the historical states of entries (vs. a sliding window into the current states of entries) would also waste some bandwidth transmitting obsolete entry states, and could result in missed entries if someone writing an entry does a lot of tweaking and publishes each tweak (thus filling their feed document with versions of a single entry), which, though sloppy methodology, is probably not entirely uncommon--just my guess. Polling combined with diffs of the current state of entries would use similar bandwidth to push... > and processing resources ...and wouldn't require the server to keep track of all of its subscribers, and would result in bandwidth usage being spread over time better than push, assuming push servers push new entries out to everyone as quickly as possible after they're published. Both methods have their advantages, many more of which could be listed on either side, I'm sure. > While the use of push-based aggregators may not be widespread, > it does not make sense, I think, to bind Atom to the inefficient, > high-latency polling model when we know that there is a workable > alternative > approach -- which is far superior in at least some important > applications of > syndication. Agreed. But I've lost track of what aspect of Atom's architecture you are saying is bound to polling at the expense of push. Are we still talking about sliding window vs. current state? If so, what difference does that make to a push-based aggregator? From owner-atom-syntax@mail.imc.org Mon Feb 7 12:30:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20161 for ; Mon, 7 Feb 2005 12:30:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HDYfS037934; Mon, 7 Feb 2005 09:13:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HDYlb037933; Mon, 7 Feb 2005 09:13:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HDXCw037916 for ; Mon, 7 Feb 2005 09:13:33 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1506538wra for ; Mon, 07 Feb 2005 09:13:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=pAan8RdslXoaOkOfIXdGgdmmqwVTJK0m7xaOUuRz+GTaCz4MtKTHpjL7UtA0ksx7EdxL1CBGeHfbrNTCOe90iMqby57i9fQ0wtZfjLg0jImsqaf9JUhHqK80LbOmd+WOM29iuOi8yAE1WYJseaXXXKFoO3lvqPGoXEVYuEkEHQY= Received: by 10.54.28.80 with SMTP id b80mr186385wrb; Mon, 07 Feb 2005 09:13:25 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id d6sm89101wra.2005.02.07.09.13.25; Mon, 07 Feb 2005 09:13:25 -0800 (PST) Message-ID: <4207A1B0.6080604@gmail.com> Date: Mon, 07 Feb 2005 09:13:20 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +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 general model that we're shooting for, whatever we scrap together here at the last minute is not going to be completely adequate. - James M Snell 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. > > So, it is not possible for the current doc to fulfill the charter, and > this document is not ready for last call. > > wunder > > --On February 6, 2005 2:00:20 AM -0500 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. >> >> bob wyman >> >> >> > > > > > -- > Walter Underwood > Principal Architect, Verity > > From owner-atom-syntax@mail.imc.org Mon Feb 7 12:44:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23258 for ; Mon, 7 Feb 2005 12:44:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVexl039762; Mon, 7 Feb 2005 09:31:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HVer4039761; Mon, 7 Feb 2005 09:31:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVdAJ039755 for ; Mon, 7 Feb 2005 09:31:39 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17HVZCi014509 for ; Mon, 7 Feb 2005 12:31:37 -0500 (EST) Message-ID: <4207A5D7.6040704@intertwingly.net> Date: Mon, 07 Feb 2005 12:31:03 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: AtomPubIssuesList for 2005/02/07 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> In-Reply-To: <41E6D8BC.405@intertwingly.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Like I did last time, I am simply scheduling all the open format items in the hopes that we can drive this list to zero. PaceAggregationDocument PaceAggregationDocument2 PaceAggregationInSeparateSpec PaceArchiveDocument PaceClarifyDateUpdated PaceCollection PaceCommentFeeds PaceDatesXSD PaceEntriesElement PaceEntryOrder PaceExtensionConstruct PaceFeedRecursive PaceFeedState PaceFormatSecurity PaceHeadless PaceIconAndImage PaceJoinSectionSixAndTen PaceLangSpecific PaceLinkEnclosure PaceLinkRelVia PaceMultipleImages PaceMustBeWellFormed PaceNoFeedState PaceOrderSpecAlphabetically PaceProfile PaceProfileAttribute PaceRemoveInfoAndHost PaceRemoveVersionAttr PaceRepeatIdInDocument PaceSecuritySection PaceTextRules PaceXhtmlNamespaceDiv - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 12:46:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23407 for ; Mon, 7 Feb 2005 12:46:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HTTOF039495; Mon, 7 Feb 2005 09:29:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HTTYT039494; Mon, 7 Feb 2005 09:29:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HTSpq039463 for ; Mon, 7 Feb 2005 09:29:28 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020717292001100cci6ve>; Mon, 7 Feb 2005 17:29:20 +0000 Date: Mon, 7 Feb 2005 10:29:18 -0700 Subject: Re: PaceArchiveDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4207A026.30801@franklinmint.fm> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 documents makes an archive. I > don't see why we need atom:archive after all. > If Atom Documents are not allowed to contain multiple instances of a particular resource, then archiving the states of an entry would require the feed to be split into more, smaller feed documents any time an entry is edited without many other entries being published in between edits. For example, if you published an entry, decided to revise a paragraph and published again, found a misspelling and published again, and then fixed and published another misspelling, you'd need four documents, two of which would only contain one entry. Doable, yes. But a little ugly. If, on the other hand, a feed document is a sliding window into the historical states on entries (and thus, must allow multiple instances of particular entries), and if we don't want to archive the state of the feed, then we don't need a separate archive document type. 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. From owner-atom-syntax@mail.imc.org Mon Feb 7 12:46:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23435 for ; Mon, 7 Feb 2005 12:46:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HV5hb039681; Mon, 7 Feb 2005 09:31:05 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HV5B3039680; Mon, 7 Feb 2005 09:31:05 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr3.netsolmail.com (omr3.netsolmail.com [216.168.230.164]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HV46q039672 for ; Mon, 7 Feb 2005 09:31:05 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr3.netsolmail.com (8.12.10/8.12.10) with ESMTP id j17HUTmm019406; Mon, 7 Feb 2005 12:30:35 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COJ57980 (AUTH bob@wyman.us); Mon, 7 Feb 2005 12:30:24 -0500 (EST) Message-Id: <200502071730.COJ57980@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: PaceArchiveDocument posted Date: Mon, 7 Feb 2005 12:26:06 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <64D90D42-7922-11D9-88AE-003065EA6144@geckotribe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUNMoAuifVDXqFUT8era//sBSbYqAABJZLA Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > foo:bar/a > ... > > ...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. Providing an explicit revision number exclusively in atom:archives has both advantages and costs. If we assume that revision numbers start at 0 or 1 and increase monotonically, then revision numbers gets us: 1. The ability to name or explicitly identify different versions of an entry. 2. The ability to determine the order in which entries were written -- independent of document order. 3. The ability to detect "missing" entry versions. The cost of the three benefits above is, of course, the increased complexity that comes from needing to maintain the version number associated with an entry. Given that "revision" is an attribute which is not to be stored in a normal feed document, this means that the feed document itself cannot be used as the primary entry storage mechanism -- as is the case in some systems today. In order to maintain revision numbers, a site that provided an archive would have to have storage/memory external to the feed document. The feed document could not be considered a complete representation of even the current the state of the feed since part of the state of the feed (the revision numbers of the current entries) would be stored externally to the feed. The first two benefits of version numbers can be had without a requirement for maintaining any state if we make the version number a DateTime. The requirement for saving state external to the feed document could be removed by simply permitting the revision number to appear in the feed document. Is the third benefit -- detection of missing entries -- worth the cost of requiring that state be maintained? Is it worth it in light of the fact that a "stateless" alternative exists that provides all the other benefits? Is a revision attribute such a "bad thing" that it is really necessary to increase the complexity of the system by requiring that it be stored and maintained external to the feed document itself? Wouldn't it be easier to just allow sites that archive to include the revision number in their feed documents? Given the two arguments above, it would seem that atom:modified (must be updated on the change of any byte in an entry) would provide all of the benefits that appear to be desired with the exception of "missing" entry detection. Of course, if we went a step further and said that the unique identifier for an entry was the concatenation of atom:id + (atom:revision OR atom:modified), then we would no longer require the archive document type at all... But, I won't go there... bob wyman From owner-atom-syntax@mail.imc.org Mon Feb 7 12:49:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23613 for ; Mon, 7 Feb 2005 12:49:46 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVoG3039784; Mon, 7 Feb 2005 09:31:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HVo3Z039783; Mon, 7 Feb 2005 09:31:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVnmY039772 for ; Mon, 7 Feb 2005 09:31:49 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1512794wra for ; Mon, 07 Feb 2005 09:31:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SPnfZlGWhBkF/Okd7xuoy+IlyOaN5Oejir94xBRaE+RCBgWB7LaquOEyL5H0/z4gpPWlylfoG46jWfQs0z1txSSvoqvcxV//tsjeZdlbHs3LFsYqZSv9zIiIik2QTMthcfx5njrRwovVrea1a5IDYagcK4aspeD6E1ztroaeUlw= Received: by 10.54.57.28 with SMTP id f28mr100171wra; Mon, 07 Feb 2005 09:31:41 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 43sm339009wri.2005.02.07.09.31.40; Mon, 07 Feb 2005 09:31:41 -0800 (PST) Message-ID: <4207A5F7.2040207@gmail.com> Date: Mon, 07 Feb 2005 09:31:35 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre , atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> <4207A026.30801@franklinmint.fm> In-Reply-To: <4207A026.30801@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 snapshot of a given point in time designed to allow others to read my entries without visiting my site. When I archive, what I want to archive are the entries, not the feed. does not make any sense to me. does. (ignore the angle brackets for now, I'm not trying to promote the idea of the archive element, I'm just illustrating my point). Now, if I had my way, I would *probably* spec this out as: * Archives work fundamentally on the entry level. * An archived entry consists of all versions of the entry. * Feeds are only archived as they relate to archived entries. For example, if a given entry has an associated comments feed, or some form of nested discussion feed, etc. Such feeds are logically considered part of the metadata of the entry. - James M Snell 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 documents makes an archive. I > don't see why we need atom:archive after all. > > Robert Sayre > > From owner-atom-syntax@mail.imc.org Mon Feb 7 12:49:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23639 for ; Mon, 7 Feb 2005 12:49:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hd28T040357; Mon, 7 Feb 2005 09:39:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Hd2uW040356; Mon, 7 Feb 2005 09:39:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hd1MK040350 for ; Mon, 7 Feb 2005 09:39:01 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyCqf-0003fz-UK; Mon, 07 Feb 2005 17:38:58 +0000 Message-ID: <4207A7B1.20403@franklinmint.fm> Date: Mon, 07 Feb 2005 12:38:57 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: >> > If Atom Documents are not allowed to contain multiple instances of a > particular resource, then archiving the states of an entry would require > the feed to be split into more, smaller feed documents any time an entry > is edited without many other entries being published in between edits. > For example, if you published an entry, decided to revise a paragraph > and published again, found a misspelling and published again, and then > fixed and published another misspelling, you'd need four documents, two > of which would only contain one entry. Doable, yes. But a little ugly. > No, I'm saying I would regenerate a feed with every entry in it every time I make a change. Then, I would check it into Subversion. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 12:52:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23817 for ; Mon, 7 Feb 2005 12:52:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVMrO039732; Mon, 7 Feb 2005 09:31:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HVMpA039731; Mon, 7 Feb 2005 09:31:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HVMcn039724 for ; Mon, 7 Feb 2005 09:31:22 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyCjG-0003Ys-Ha; Mon, 07 Feb 2005 17:31:18 +0000 Message-ID: <4207A5E6.1010507@franklinmint.fm> Date: Mon, 07 Feb 2005 12:31:18 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> <4207A1B0.6080604@gmail.com> In-Reply-To: <4207A1B0.6080604@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 requirements > and a general model that we're shooting for, whatever we scrap together > here at the last minute is not going to be completely adequate. The word "archive" shouldn't have been in the charter. Since no one even bothered to define the term over the past 8 months, I will do it now. Archiving -- It must be possible to serialize a complete collection of entries using the Atom Format. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 12:52:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23855 for ; Mon, 7 Feb 2005 12:52:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HciRU040330; Mon, 7 Feb 2005 09:38:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HciVl040329; Mon, 7 Feb 2005 09:38:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HchmB040320 for ; Mon, 7 Feb 2005 09:38:43 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 98358C9; Mon, 7 Feb 2005 09:38:38 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17HcbLf000504; Mon, 7 Feb 2005 09:38:37 -0800 (PST) Date: Mon, 07 Feb 2005 09:38:42 -0800 From: Walter Underwood To: atom-syntax@imc.org Subject: PaceCaching posted Message-ID: <0BFF89D2D6396A8478AE0002@Wunders-Computer.local> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I was holding this back as out of scope and too close to the deadline, but now that we are talking about sliding windows and delayed, cached state, it is quite relevant. This proposal uses HTTP caching algorithms, but does not require an HTTP transport. Atom over other transports can use these algorithms. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 12:58:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24314 for ; Mon, 7 Feb 2005 12:58:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hp2fk041911; Mon, 7 Feb 2005 09:51:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Hp2cm041910; Mon, 7 Feb 2005 09:51:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hp1LN041903 for ; Mon, 7 Feb 2005 09:51:01 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4207A5D7.6040704@intertwingly.net> References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> Date: Mon, 7 Feb 2005 09:50:57 -0800 To: Atom-Syntax From: Paul Hoffman Subject: Re: AtomPubIssuesList for 2005/02/07 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks, Sam. Everyone: as Tim and I said last week, this is the last set of Paces we are considering for inclusion in the format document. If it's not on this list, it isn't considered unless you can show that there is a dire technical or security flaw in the document. Please comment on each Pace separately. Even if you sent in a +1, 0, or -1 previously on a particular Pace, send it in again. Hopefully, add a short or long comment on why you feel it should or should not be considered part of the Atom core. Aggregated lists are cute, but greatly hurt the ability to hold a conversation. Some of the Paces in this last round cover interesting and useful topics. Note, however, that "interesting and useful" does not mean core to Atom. We don't/can't have a strict definition of what is core to the protocol, but after over a year, many of us have a good feeling for that. And, let's remember to have useful Subject: lines, OK? If a thread changes direction, please change the subject line. Thanks! --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 13:03:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24721 for ; Mon, 7 Feb 2005 13:03:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HmmhP041661; Mon, 7 Feb 2005 09:48:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Hmmbx041660; Mon, 7 Feb 2005 09:48:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hmlgg041647 for ; Mon, 7 Feb 2005 09:48:47 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020717483601200fvedae>; Mon, 7 Feb 2005 17:48:41 +0000 Date: Mon, 7 Feb 2005 10:48:35 -0700 Subject: Re: PaceArchiveDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4207A1B0.6080604@gmail.com> Message-Id: <7D768018-7930-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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. * Entry Document: A document, whose document element is , which contains a single Entry Representation. * Feed: An abstract term describing a stream of Entry Representations. * Feed Document: No such thing--replaced by Collection Documents and Archive Documents. * Collection: Entry Representations of the current states of the Entries from a Feed. * Collection Document: A document, whose document element is , which contains a Collection or a portion of a Collection. * Archive: Entry Representations of the historical states of the Entries from a Feed. * Archive Document: A document, whose document element is , which contains an Archive or a portion of an Archive. Archive documents may contain multiple Entry Representations of the same Entry. Publishers may choose to publish only Collection Documents, only Archive Documents, only Entry Documents, or any combination of these. So, for example, a publisher who does not track the historical states of their Entries might publish only a Collection Document. A publisher who DOES track the historical states of their Entries might publish only an Archive Document, or both Collection and Archive Documents, or only a Collection Document. Processing an Archive Document would be slightly more complicated than processing a Collection Document for clients that don't track the history of a Feed--for example, scripts that simply display the current contents of a Document on a website, because they might need to choose one from among multiple Entry Representations of the same Entry for display or other processing. On Monday, February 7, 2005, at 10:13 AM, 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 requirements > and a general model that we're shooting for, whatever we scrap together > here at the last minute is not going to be completely adequate. > > - James M Snell > > 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. >> So, it is not possible for the current doc to fulfill the charter, and >> this document is not ready for last call. >> wunder >> --On February 6, 2005 2:00:20 AM -0500 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. >>> >>> bob wyman >>> >>> >>> >> -- >> Walter Underwood >> Principal Architect, Verity > From owner-atom-syntax@mail.imc.org Mon Feb 7 13:07:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24894 for ; Mon, 7 Feb 2005 13:07:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hr7E9042282; Mon, 7 Feb 2005 09:53:07 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Hr7jH042281; Mon, 7 Feb 2005 09:53:07 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hr3BL042264; Mon, 7 Feb 2005 09:53:04 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4207A0BB.5090103@dehora.net> References: <420752AC.6040805@dehora.net> <4207A0BB.5090103@dehora.net> Date: Mon, 7 Feb 2005 09:53:00 -0800 To: Bill de =?iso-8859-1?Q?h=D3ra?= From: Paul Hoffman Subject: Re: PaceJoinSectionSixAndTen Cc: Atom Syntax Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit At 5:09 PM +0000 2/7/05, Bill de hÓra wrote: >Paul Hoffman wrote: >> >>-1. IETF documents have to have a "Security Considerations" section >>that describes general security issues. In no cases that I know of >>do they contain protocol specification. See RFC 3552 for more info. > >Is that -1 to the proposed title or -1 to having one section? The latter. In IETF documents, there should be a section that tells you how to do security, and another section that shows the bigger picture about security (such as known threats, other interesting security work, and so on). --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 13:07:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24915 for ; Mon, 7 Feb 2005 13:07:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HtvD6042592; Mon, 7 Feb 2005 09:55:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Htvm0042591; Mon, 7 Feb 2005 09:55:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HtuBG042583 for ; Mon, 7 Feb 2005 09:55:56 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 09:55:53 -0800 To: Atom WG From: Paul Hoffman Subject: PaceArchiveDocument Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -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 From owner-atom-syntax@mail.imc.org Mon Feb 7 13:07:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24941 for ; Mon, 7 Feb 2005 13:07:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I0xip043080; Mon, 7 Feb 2005 10:00:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I0xA9043079; Mon, 7 Feb 2005 10:00:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I0vvG043070 for ; Mon, 7 Feb 2005 10:00:58 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 10:00:55 -0800 To: Atom WG From: Paul Hoffman Subject: PaceEntryOrder Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: +1. It is a simple clarification that shows the intention without restricting anyone. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 13:07:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24961 for ; Mon, 7 Feb 2005 13:07:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HnsWV041757; Mon, 7 Feb 2005 09:49:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HnsTe041756; Mon, 7 Feb 2005 09:49:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.195]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HnrD5041746 for ; Mon, 7 Feb 2005 09:49:54 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1591607wri for ; Mon, 07 Feb 2005 09:49:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=A3j3k+8znWxq1ZGMmsfSrRMksAQY/aSmSZ+hINgWX4i778NNtNnqOiSYCKdMipdVVZsUqO8k+wOOcU4zDiDq0+RlgSA3idNUgOFW7Wn5iG42MaNcXeHXlbAo8jT/3uoJDZCKVZyhK/bXUyHfYu6CbCjnnDluIdxBlCBIKKoLb0k= Received: by 10.54.51.61 with SMTP id y61mr62395wry; Mon, 07 Feb 2005 09:49:39 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id d7sm94044wra.2005.02.07.09.49.38; Mon, 07 Feb 2005 09:49:39 -0800 (PST) Message-ID: <4207AA2D.5040600@gmail.com> Date: Mon, 07 Feb 2005 09:49:33 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre , atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <4207A7B1.20403@franklinmint.fm> In-Reply-To: <4207A7B1.20403@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 archive for one minor edit? That would be kind of like taking all the source code for a given project, zipping it up into a single zip file and checking that into subversion. Sure, it would work, but dang that's nasty (not that it's not being done). Better to archive individual entries. Sure, archiving of feeds can be done also, but archiving feeds is separate from archiving entries. They are separate documents, treat them separately. - James M Snell Robert Sayre wrote: > > Antone Roundy wrote: > >>> >> If Atom Documents are not allowed to contain multiple instances of a >> particular resource, then archiving the states of an entry would >> require the feed to be split into more, smaller feed documents any >> time an entry is edited without many other entries being published in >> between edits. For example, if you published an entry, decided to >> revise a paragraph and published again, found a misspelling and >> published again, and then fixed and published another misspelling, >> you'd need four documents, two of which would only contain one entry. >> Doable, yes. But a little ugly. >> > > No, I'm saying I would regenerate a feed with every entry in it every > time I make a change. Then, I would check it into Subversion. > > Robert Sayre > > From owner-atom-syntax@mail.imc.org Mon Feb 7 13:08:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24991 for ; Mon, 7 Feb 2005 13:08:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HweNQ042870; Mon, 7 Feb 2005 09:58:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HwesA042869; Mon, 7 Feb 2005 09:58:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HwcA0042861 for ; Mon, 7 Feb 2005 09:58:39 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 7 Feb 2005 09:58:37 -0800 To: Atom WG From: Paul Hoffman Subject: Removing your old Paces from consideration Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Someone pointed out that some of the Paces in the current rotation have been informally withdrawn by their authors. Good point. If you have such a Pace, please send mail to the list saying so, and Sam can remove it from the wiki. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 13:24:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26688 for ; Mon, 7 Feb 2005 13:24:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I5YoT043570; Mon, 7 Feb 2005 10:05:34 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I5YX0043569; Mon, 7 Feb 2005 10:05:34 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I5XUB043547; Mon, 7 Feb 2005 10:05:33 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDGL-0003ze-QM; Mon, 07 Feb 2005 18:05:29 +0000 Message-ID: <4207ADE9.9070004@franklinmint.fm> Date: Mon, 07 Feb 2005 13:05:29 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: PaceClarifyDateUpdated References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. Doesn't make sense or add value to the document. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 13:24:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26691 for ; Mon, 7 Feb 2005 13:24:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I6suh043695; Mon, 7 Feb 2005 10:06:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I6skX043694; Mon, 7 Feb 2005 10:06:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I6ruj043681; Mon, 7 Feb 2005 10:06:53 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDHe-00040k-7U; Mon, 07 Feb 2005 18:06:50 +0000 Message-ID: <4207AE39.7010507@franklinmint.fm> Date: Mon, 07 Feb 2005 13:06:49 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: PaceEntryOrder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > +1. It is a simple clarification that shows the intention without > restricting anyone. +1. Agree in full. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 13:25:38 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26764 for ; Mon, 7 Feb 2005 13:25:38 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I4CiT043426; Mon, 7 Feb 2005 10:04:12 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I4CpL043425; Mon, 7 Feb 2005 10:04:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I4BgA043409; Mon, 7 Feb 2005 10:04:11 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDF1-0003yj-UE; Mon, 07 Feb 2005 18:04:08 +0000 Message-ID: <4207AD97.8020504@franklinmint.fm> Date: Mon, 07 Feb 2005 13:04:07 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom WG Subject: Re: PaceArchiveDocument References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 From owner-atom-syntax@mail.imc.org Mon Feb 7 13:27:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26914 for ; Mon, 7 Feb 2005 13:27:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I8rk7044099; Mon, 7 Feb 2005 10:08:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I8r3n044098; Mon, 7 Feb 2005 10:08:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I8p4p044091; Mon, 7 Feb 2005 10:08:51 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <0BFF89D2D6396A8478AE0002@Wunders-Computer.local> References: <0BFF89D2D6396A8478AE0002@Wunders-Computer.local> Date: Mon, 7 Feb 2005 10:08:48 -0800 To: Walter Underwood , atom-syntax@imc.org From: Paul Hoffman Subject: Re: PaceCaching posted Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:38 AM -0800 2/7/05, Walter Underwood wrote: >I was holding this back as out of scope and too close to the deadline, >but now that we are talking about sliding windows and delayed, cached >state, it is quite relevant. Sorry, this is too late for consideration for the Atom core. Even if you had turned it in on time, I would give it a -1 for not being essential to the core for the Atom format. Atom will be distributed over many protocols, HTTP being one of them. Having said that, I think this would be an excellent extension, one that might keep the folks who don't understand HTTP scalability but feel free to talk about it anyway at bay. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 13:29:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27057 for ; Mon, 7 Feb 2005 13:29:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I9uOX044211; Mon, 7 Feb 2005 10:09:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I9uY5044207; Mon, 7 Feb 2005 10:09:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail01.svc.cra.dublin.eircom.net (mail01.svc.cra.dublin.eircom.net [159.134.118.17]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17I9tqo044185 for ; Mon, 7 Feb 2005 10:09:55 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 25928 messnum 7743512 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 18:09:49 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail01.svc.cra.dublin.eircom.net (qp 25928) with SMTP; 7 Feb 2005 18:09:49 -0000 Message-ID: <4207AEE7.7030902@dehora.net> Date: Mon, 07 Feb 2005 18:09:43 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman CC: Atom Syntax Subject: Re: PaceJoinSectionSixAndTen References: <420752AC.6040805@dehora.net> <4207A0BB.5090103@dehora.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > The latter. In IETF documents, there should be a section that tells you > how to do security, and another section that shows the bigger picture > about security (such as known threats, other interesting security work, > and so on). I can tell this isn't worth arguing about :) I've withdrawn the pace and notified Sam. cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 13:30:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27181 for ; Mon, 7 Feb 2005 13:30:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17I8S1w044044; Mon, 7 Feb 2005 10:08:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17I8Sfl044043; Mon, 7 Feb 2005 10:08:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17I8RFj044018 for ; Mon, 7 Feb 2005 10:08:28 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 12412 messnum 5126148 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 18:08:22 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 12412) with SMTP; 7 Feb 2005 18:08:22 -0000 Message-ID: <4207AE91.6060706@dehora.net> Date: Mon, 07 Feb 2005 18:08:17 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Atom-Syntax , Paul Hoffman Subject: Re: AtomPubIssuesList for 2005/02/07 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Like I did last time, I am simply scheduling all the open format items > in the hopes that we can drive this list to zero. > > PaceJoinSectionSixAndTen Hi Sam, I'd like to withdraw this one from consideration, it doesn't fit with the IETF way (...mumbles darkly about the ietf way...). cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 13:31:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27281 for ; Mon, 7 Feb 2005 13:31:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IKDs3045072; Mon, 7 Feb 2005 10:20:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IK4D7045018; Mon, 7 Feb 2005 10:20:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net ([66.98.134.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IHLRX044568 for ; Mon, 7 Feb 2005 10:19:58 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDPI-00044o-LZ for atom-syntax@imc.org; Mon, 07 Feb 2005 18:14:44 +0000 Message-ID: <4207B014.5000200@franklinmint.fm> Date: Mon, 07 Feb 2005 13:14:44 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: PaceDatesXSD Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. Our AD has told us how to write this section, so the Pace just adds the regex, which I'm in favor of. Sam's suggestion at the end could easily be accomodated with a sentence saying "As a result, the date values are valid according to [RFC3339], [XML-SCHEMA], and [w3cdtf]." Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 13:32:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27382 for ; Mon, 7 Feb 2005 13:32:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IK2YQ045032; Mon, 7 Feb 2005 10:20:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IIfpN044598; Mon, 7 Feb 2005 10:18:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net ([204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17ICHp1044359 for ; Mon, 7 Feb 2005 10:15:11 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020718113501200g0ovhe>; Mon, 7 Feb 2005 18:11:35 +0000 Date: Mon, 7 Feb 2005 11:11:33 -0700 Subject: Re: PaceArchiveDocument posted Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200502071730.COJ57980@ms8.netsolmail.com> Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, February 7, 2005, at 10:26 AM, Bob Wyman wrote: > Antone Roundy wrote: >> >> foo:bar/a >> ... >> >> ...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. > Providing an explicit revision number exclusively in atom:archives > has both advantages and costs. > If we assume that revision numbers start at 0 or 1 and increase > monotonically, then revision numbers gets us: > 1. The ability to name or explicitly identify different versions of > an entry. > 2. The ability to determine the order in which entries were written > -- independent of document order. > 3. The ability to detect "missing" entry versions. > The cost of the three benefits above is, of course, the increased > complexity that comes from needing to maintain the version number > associated > with an entry. Only if the version number for a particular Entry Representation needs to remain constant. I'd be fine with it either way--simplicity and only #2 (and limited #1--you can do it within the context of a particular instance of the archive, but can't be sure it won't change when you download the archive again) vs. storing the version number and getting all 3. > The first two benefits of version numbers can be had without a > requirement for maintaining any state if we make the version number a > DateTime. Of course, you'd have to store the DateTime. It's more likely that people are already doing that, so for those that are, this would be preferable. Those who aren't are likely not storing the historical states of the entry at all. > Is a revision attribute such a "bad thing" that it is really > necessary to increase the complexity of the system by requiring that > it be > stored and maintained external to the feed document itself? Wouldn't > it be > easier to just allow sites that archive to include the revision number > in > their feed documents? I'd have no problem with allowing that. > Given the two arguments above, it would seem that atom:modified > (must be updated on the change of any byte in an entry) would provide > all of > the benefits that appear to be desired with the exception of "missing" > entry > detection. True. Rather than going back into the whole discussion of dates, we could let people who want to get benefits #1 and #2 can store dc:modified (since atom:modified) doesn't currently exist, and those who don't do that can either invent their own extension like @revision. So archive documents as defined in Atom wouldn't include either, and the market would show us which would prevail. I'm feeling a little apathetic about exactly how we do it at the moment. From owner-atom-syntax@mail.imc.org Mon Feb 7 13:38:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27997 for ; Mon, 7 Feb 2005 13:38:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IKEeY045084; Mon, 7 Feb 2005 10:20:17 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IK80f045042; Mon, 7 Feb 2005 10:20:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IJasH044811 for ; Mon, 7 Feb 2005 10:20:03 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDS9-00046d-KZ for atom-syntax@imc.org; Mon, 07 Feb 2005 18:17:41 +0000 Message-ID: <4207B0C5.3080909@franklinmint.fm> Date: Mon, 07 Feb 2005 13:17:41 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: PaceSecuritySection Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. Says all that we need to without getting into HTML too deeply. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 13:42:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28403 for ; Mon, 7 Feb 2005 13:42:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IYECF047081; Mon, 7 Feb 2005 10:34:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IYEib047080; Mon, 7 Feb 2005 10:34:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IYDnQ047049 for ; Mon, 7 Feb 2005 10:34:13 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 5F13CA8 for ; Mon, 7 Feb 2005 10:34:06 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17IY6Lf000781 for ; Mon, 7 Feb 2005 10:34:06 -0800 (PST) Date: Mon, 07 Feb 2005 10:53:44 -0800 From: Walter Underwood To: atom-syntax@imc.org Subject: Re: PaceCaching posted Message-ID: <11F6BA9D1D9881C06C2C0D33@diva.verity.com> In-Reply-To: References: <0BFF89D2D6396A8478AE0002@Wunders-Computer.local> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is not restricted to HTTP. It uses HTTP's cache age algorithms, because they are very carefully designed and have proven effective. But it can be used for any local copy in an Atom client. wunder --On Monday, February 07, 2005 10:08:48 AM -0800 Paul Hoffman wrote: > At 9:38 AM -0800 2/7/05, Walter Underwood wrote: >> I was holding this back as out of scope and too close to the deadline, >> but now that we are talking about sliding windows and delayed, cached >> state, it is quite relevant. > > Sorry, this is too late for consideration for the Atom core. Even if you had turned it in on time, I would give it a -1 for not being essential to the core for the Atom format. Atom will be distributed over many protocols, HTTP being one of them. Having said that, I think this would be an excellent extension, one that might keep the folks who don't understand HTTP scalability but feel free to talk about it anyway at bay. > > --Paul Hoffman, Director > --Internet Mail Consortium > -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Feb 7 13:44:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28558 for ; Mon, 7 Feb 2005 13:44:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IZlgs047228; Mon, 7 Feb 2005 10:35:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IZlCE047227; Mon, 7 Feb 2005 10:35:47 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IZknF047218 for ; Mon, 7 Feb 2005 10:35:46 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDjX-0004KY-Mq for atom-syntax@imc.org; Mon, 07 Feb 2005 18:35:39 +0000 Message-ID: <4207B4FB.2000005@franklinmint.fm> Date: Mon, 07 Feb 2005 13:35:39 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: PaceFormatSecurity Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. Covers HTML in too much detail, though it's still inadequate coverage. This is isn't our problem. I blame the W3C :) Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 13:46:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28953 for ; Mon, 7 Feb 2005 13:46:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hb4Z7040230; Mon, 7 Feb 2005 09:37:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Hb4qc040229; Mon, 7 Feb 2005 09:37:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Hb4ng040222 for ; Mon, 7 Feb 2005 09:37:04 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j17Har401437 for ; Mon, 7 Feb 2005 09:36:57 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBJY9G01.Q05; Mon, 7 Feb 2005 09:36:52 -0800 Message-ID: <4207A734.7050204@aol.net> Date: Mon, 07 Feb 2005 09:36:52 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Walter Underwood , atom-syntax@imc.org Subject: Re: PaceArchiveDocument posted References: <200502060700.CNY83294@ms8.netsolmail.com> <4207A026.30801@franklinmint.fm> In-Reply-To: <4207A026.30801@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 documents makes an archive. I > don't see why we need atom:archive after all. > > Robert Sayre > +1 [1]. Specifically, I think that we can fulfill the charter's 'support for archives' requirement [2] with the existing syntax plus the facilities provided by the protocol. How an archive is stored is something I'd be happy leaving to 'archiver' implementations in much the same way we leave such details to 'aggregator' implementations. I can certainly see value in standardizing document formats for archivers to allow interoperability; but I don't think the benefit is worth the cost, and I don't think the charter requires it. -John [1] Though I actually disagree that just a series of feed documents makes an archive -- what about non-entry resources? Where are my cat pictures? [2] At least for the types of archives I think are important. From owner-atom-syntax@mail.imc.org Mon Feb 7 13:47:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29044 for ; Mon, 7 Feb 2005 13:47:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IbU4n047398; Mon, 7 Feb 2005 10:37:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IbUSW047397; Mon, 7 Feb 2005 10:37:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IbUwk047391 for ; Mon, 7 Feb 2005 10:37:30 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyDlG-0004L0-Is for atom-syntax@imc.org; Mon, 07 Feb 2005 18:37:26 +0000 Message-ID: <4207B566.6010409@franklinmint.fm> Date: Mon, 07 Feb 2005 13:37:26 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax Subject: PaceMultipleImages Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit "Some feel that since the could contain text, multiple instances ought to be allowed for to support multilanguage." These people are wrong. -1 to the Pace. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 14:01:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00476 for ; Mon, 7 Feb 2005 14:01:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Ir4Vo049341; Mon, 7 Feb 2005 10:53:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Ir49c049340; Mon, 7 Feb 2005 10:53:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Ir4Si049318 for ; Mon, 7 Feb 2005 10:53:04 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j17IHk403192 for ; Mon, 7 Feb 2005 10:17:46 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBK05L03.I04 for ; Mon, 7 Feb 2005 10:17:45 -0800 Message-ID: <4207B0C9.2080603@aol.net> Date: Mon, 07 Feb 2005 10:17:45 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom WG Subject: Re: PaceArchiveDocument References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 to the Pace. The current syntax sufficiently meets the 'support for archives' charter, and extensions are possible. -John From owner-atom-syntax@mail.imc.org Mon Feb 7 14:12:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01119 for ; Mon, 7 Feb 2005 14:12:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J52hU051161; Mon, 7 Feb 2005 11:05:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J527c051160; Mon, 7 Feb 2005 11:05:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J52kX051146 for ; Mon, 7 Feb 2005 11:05:02 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050207190456016004fk6oe>; Mon, 7 Feb 2005 19:04:56 +0000 Date: Mon, 7 Feb 2005 12:04:55 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceNoFeedState From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <27177296-793B-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. There are too many little details that we haven't worked out in exactly how to reconstruct the state of a feed to try to define it now. From owner-atom-syntax@mail.imc.org Mon Feb 7 14:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01192 for ; Mon, 7 Feb 2005 14:13:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J3JX2050944; Mon, 7 Feb 2005 11:03:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J3J4w050943; Mon, 7 Feb 2005 11:03:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J3IRn050927 for ; Mon, 7 Feb 2005 11:03:19 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1615980wri for ; Mon, 07 Feb 2005 11:03:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=BbCOhsDs6zUzeSGe6n6dzTHQHn34zGDfMM8VtKaIEyiKIDc5K/EUOjD37/G/3qA5Uzid36RMAEXuBhZU0pm44RbqdN9A+Sz1Bkdw+4a8Z9U7khqTRSkwLLoA06AIyRaoHuyQQ+K18EeIl06IuXXfxjlmy7VWISdytiVLlEJKIOE= Received: by 10.54.22.38 with SMTP id 38mr62865wrv; Mon, 07 Feb 2005 11:03:11 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 66sm71642wra.2005.02.07.11.03.11; Mon, 07 Feb 2005 11:03:11 -0800 (PST) Message-ID: <4207BB69.6060702@gmail.com> Date: Mon, 07 Feb 2005 11:03:05 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby , atom-syntax@imc.org Subject: Re: AtomPubIssuesList for 2005/02/07 References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Like I did last time, I am simply scheduling all the open format items > in the hopes that we can drive this list to zero. > > PaceAggregationDocument > PaceAggregationDocument2 > PaceFeedRecursive -1. These should be deferred, see PaceAggregationInSeparateSpec > PaceAggregationInSeparateSpec +1. Obviously since I wrote it :-) > PaceArchiveDocument +0. We need to clarify 1) requirements for archiving 2) model for archiving 3) definition of archiving before we can settle on a syntax. I agree with the notion that the current syntax *can* support archiving, but as there does not appear to have been significant discussion on it, until we agree on requirements/model it is hard to sufficiently analyze. > PaceClarifyDateUpdated > PaceDatesXSD > PaceFormatSecurity > PaceLangSpecific > PaceMustBeWellFormed > PaceSecuritySection > PaceTextRules > PaceXhtmlNamespaceDiv +0. Don't know enough about 'em to say. > PaceCollection -1. no compelling need for this > PaceCommentFeeds +0.5. I like the general idea, but it may need a bit more fleshing out. > PaceEntriesElement -1. no compelling need for this > PaceEntryOrder +0. don't care either way > PaceExtensionConstruct +1. this is looking good > PaceFeedState -1. Just doesn't seem critically necessary. Also, the hyperbole "If we don't specify this, Atom will be unusable for many applications" is somewhat annoying. > PaceHeadless -0.5. I like the idea of getting rid of head, but not in this way. There should be a means of referencing what feed an entry is part of, but I'm willing to back off my original assertion that it should be part of the core. > PaceIconAndImage +0.5. I don't quite understand while these two elements can't be merged? It just seems silly to have two separate elements that both specify image URIs when the only difference between them is aspect ratio. It would make far more sense to me if we had . > PaceLinkEnclosure +1. just makes sense > PaceLinkRelVia > PaceRemoveInfoAndHost +0. I don't think it is critical for the core, but whatever. > PaceMultipleImages -1. Silly. > PaceNoFeedState +1 > PaceOrderSpecAlphabetically +0 > PaceProfile > PaceProfileAttribute +1. We need to work out the details between Marks proposal and mine, but I think in general this type of mechanism would be much more useful than the existing version attribute. > PaceRemoveVersionAttr +1. Replace with @profile > PaceRepeatIdInDocument -1. Need to figure out the whole archiving discussion first - James M Snell From owner-atom-syntax@mail.imc.org Mon Feb 7 14:13:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01237 for ; Mon, 7 Feb 2005 14:13:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J4pwU051133; Mon, 7 Feb 2005 11:04:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J4pQ6051132; Mon, 7 Feb 2005 11:04:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J4k3t051087 for ; Mon, 7 Feb 2005 11:04:46 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j17J4fqp014328; Mon, 7 Feb 2005 14:04:42 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COJ99627 (AUTH bob@wyman.us); Mon, 7 Feb 2005 14:04:39 -0500 (EST) Message-Id: <200502071904.COJ99627@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: "'Antone Roundy'" , Subject: RE: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 14:00:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUNO3siDNxt1gfmT/SiHmY5fMdEygAB9Smw Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > [polling] would result in bandwidth usage being spread over time > better than push, assuming push servers push new entries out to > everyone as quickly as possible after they're published. At PubSub, we operate both a push and a pull service. We know from experience that the push service results in drastically less bandwidth per user then the polling service does. This is not based on theory -- rather the statement is based on real empirical evidence of running both services side by side. The bandwidth savings of the push service comes from the fact that we don't have to handle the poll requests themselves and we never publish the same item twice to a single subscriber as is inevitably the case with a multi-entry polled RSS/Atom file. In order to demonstrate polling at its most efficient, I defined and convinced a number of folk to implement RFC3229+feed. This HTTP extension eliminates the problem with sending multiple copies of messages to people and the resulting drop in bandwidth requirements for those who poll and use RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still consumes more bandwidth then the push service. Once again, this ain't theory, it is experience. > I've lost track of what aspect of Atom's architecture you > are saying is bound to polling at the expense of push. There are several "Feed-oriented" or "polling oriented" discussions going on: 1. The requirement that feeds not be permitted to contain multiple entries that have the same atom:id. This requirement prevents push based system from using feeds as "logs" or "histories" of messages sent. For instance, at PubSub, the Atom file which is associated with every subscription contains a stream of entries that are the entries that either were or would have been sent to the client if it had been connected. The first thing a client does on starting up is to read the Atom file in order to synchronize state with the server. Thus, the feed is actually just a trace of the messages sent. This probably sounds weird if you're feed-focused; however, it makes perfect sense if you are pushing entries. 2. Significance of the order of entries in feeds. A push-fed client only sees feeds in edge cases (like the PubSub synchronization usage discussed above). Because a push-fed client receives a stream of entries -- not feeds, it can only see chronological order unless order is encoded within the entry itself. Any requirement that document order is significant (and some are still suggesting it is) means that a push-based system must push entire feeds rather then individual entries. The bandwidth costs of doing so would be completely unacceptable. (Things like ordered lists should be handled by having entries that contain ordered lists. Exploiting the anecdotal attributes of the atom:feed document and the practices of current aggregators is NOT reasonable.) 3. The absence of a revision id or atom:modified. The feed-ists don't see the need for revision numbers in part because they are focused on feeds rather than entries. If you live in the world of entries -- as a push system does -- then the need to distinguish multiple versions of the same entry becomes much, much more important. I have an additional set of concerns that are based on our experience as generators of aggregate feeds. The problem is that we are at the mercy of the creators of feeds... The rules say, as they should, that we're not supposed to change the atom:id of something that we extract from a feed. Thus, when we generate results, we should use the atom:id's that we found in the source entries. However, if someone fails to create really unique atom:id's, we are left wondering what to do... We aren't supposed to generate a feed with repeat atom:id's according to the spec, however, our users will want to see all entries that match their search terms. We have to either conform to the Atom spec by dropping one of the Entries from the results -- and thus serve our users less well, or, we have to generate new atom:id's in order to serve our users but violate the specification. In other words, we can't win. Similarly, the prohibition against multiple instances of an atom:id means that we can't implement a "show me all versions" feature using Atom as the packaging format for the results. (No, we're not planning to do this. But, it would be good to be able to do it.) bob wyman [1] http://bobwyman.pubsub.com/main/2004/10/massive_bandwid.html From owner-atom-syntax@mail.imc.org Mon Feb 7 14:14:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01300 for ; Mon, 7 Feb 2005 14:14:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J7ud8051509; Mon, 7 Feb 2005 11:07:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J7u6a051508; Mon, 7 Feb 2005 11:07:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J7tLp051494 for ; Mon, 7 Feb 2005 11:07:55 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 6E334CD for ; Mon, 7 Feb 2005 11:07:50 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17J7nLf000990 for ; Mon, 7 Feb 2005 11:07:49 -0800 (PST) Date: Mon, 07 Feb 2005 11:07:54 -0800 From: Walter Underwood To: Atom WG Subject: Re: PaceEntryOrder Message-ID: In-Reply-To: <4207AE39.7010507@franklinmint.fm> References: <4207AE39.7010507@franklinmint.fm> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On February 7, 2005 1:06:49 PM -0500 Robert Sayre wrote: > Paul Hoffman wrote: >> >> +1. It is a simple clarification that shows the intention without >> restricting anyone. > > +1. Agree in full. -1. I don't see the benefit. Clients MAY re-order them, but that doesn't mean they MUST ignore the order. The publisher may prefer an order which cannot be expressed in the attributes. The Macintouch and BBC New feeds cited before are good examples. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 14:15:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01368 for ; Mon, 7 Feb 2005 14:15:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J8D2l051555; Mon, 7 Feb 2005 11:08:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J8D7q051553; Mon, 7 Feb 2005 11:08:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J8Cbs051540 for ; Mon, 7 Feb 2005 11:08:12 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020719080701200g6odbe>; Mon, 7 Feb 2005 19:08:07 +0000 Date: Mon, 7 Feb 2005 12:08:06 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceIconAndImage From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 if is changed to or, even better, if is allowed in . I don't care whether is allowed in entry, though I see no reason not to allow it. From owner-atom-syntax@mail.imc.org Mon Feb 7 14:16:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01509 for ; Mon, 7 Feb 2005 14:16:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J9orV051758; Mon, 7 Feb 2005 11:09:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J9o6E051757; Mon, 7 Feb 2005 11:09:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J9otd051731 for ; Mon, 7 Feb 2005 11:09:50 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020719094401100cfau3e>; Mon, 7 Feb 2005 19:09:44 +0000 Date: Mon, 7 Feb 2005 12:09:43 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceMultipleImages From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1: too messy figuring out how to render it--if people want multiple images in an entry, they can use tags in (X)HTML content to point to them. From owner-atom-syntax@mail.imc.org Mon Feb 7 14:17:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01541 for ; Mon, 7 Feb 2005 14:17:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J6uch051364; Mon, 7 Feb 2005 11:06:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17J6um1051363; Mon, 7 Feb 2005 11:06:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17J6tA5051345 for ; Mon, 7 Feb 2005 11:06:56 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020719065001200g7cvee>; Mon, 7 Feb 2005 19:06:50 +0000 Date: Mon, 7 Feb 2005 12:06:49 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceFeedState From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <6B0FE843-793B-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 to the pace (there are too many details of the pace that I disagree with or don't think would quite work). But +1 to @rel="prev|next|this". From owner-atom-syntax@mail.imc.org Mon Feb 7 14:18:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01651 for ; Mon, 7 Feb 2005 14:18:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JCJr6051975; Mon, 7 Feb 2005 11:12:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JCJ8d051974; Mon, 7 Feb 2005 11:12:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JCIsE051966 for ; Mon, 7 Feb 2005 11:12:18 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020719121301100cj3g0e>; Mon, 7 Feb 2005 19:12:13 +0000 Date: Mon, 7 Feb 2005 12:12:12 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceLinkEnclosure From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <2B9D4D47-793C-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, and +1 to calling it "attachment" instead of "enclosure". From owner-atom-syntax@mail.imc.org Mon Feb 7 14:27:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02607 for ; Mon, 7 Feb 2005 14:27:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JEpaV052241; Mon, 7 Feb 2005 11:14:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JEpSf052240; Mon, 7 Feb 2005 11:14:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JEpYL052218 for ; Mon, 7 Feb 2005 11:14:51 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050207191445016004fskle>; Mon, 7 Feb 2005 19:14:45 +0000 Date: Mon, 7 Feb 2005 12:14:44 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceSecuritySection From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <867979AC-793C-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1: Not enough information. We may not need all the detail of PaceFormatSecurity, but PaceSecuritySection goes too far the other way. From owner-atom-syntax@mail.imc.org Mon Feb 7 14:28:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02626 for ; Mon, 7 Feb 2005 14:28:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JGTZo052442; Mon, 7 Feb 2005 11:16:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JGTM3052441; Mon, 7 Feb 2005 11:16:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JGTYY052406 for ; Mon, 7 Feb 2005 11:16:29 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050207191623016004eho3e>; Mon, 7 Feb 2005 19:16:24 +0000 Date: Mon, 7 Feb 2005 12:16:22 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceFormatSecurity From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. But let's add something to the effect of "consumers MAY ignore unrecognized CSS/(X)HTML and any CSS/(X)HTML that they are not confident will not result in security problems." From owner-atom-syntax@mail.imc.org Mon Feb 7 14:33:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03126 for ; Mon, 7 Feb 2005 14:33:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLcpN053058; Mon, 7 Feb 2005 11:21:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JLc11053057; Mon, 7 Feb 2005 11:21:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLbwE053047 for ; Mon, 7 Feb 2005 11:21:37 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4207B0C5.3080909@franklinmint.fm> References: <4207B0C5.3080909@franklinmint.fm> Date: Mon, 7 Feb 2005 11:19:13 -0800 To: Atom-Syntax From: Paul Hoffman Subject: Re: PaceSecuritySection Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:17 PM -0500 2/7/05, Robert Sayre wrote: >+1. Says all that we need to without getting into HTML too deeply. Wearing my IETF hat, +1. Also, be aware that there is probably a 50% chance that we will get additions to this section from the IETF last call or from the IESG. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 14:34:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03280 for ; Mon, 7 Feb 2005 14:34:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLF1W052987; Mon, 7 Feb 2005 11:21:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JLFEh052986; Mon, 7 Feb 2005 11:21:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLEdv052972 for ; Mon, 7 Feb 2005 11:21:15 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54714 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228831AbVBGTVJ (ORCPT ); Mon, 7 Feb 2005 21:21:09 +0200 In-Reply-To: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> References: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceIconAndImage Date: Mon, 7 Feb 2005 21:21:07 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 on PaceIconAndImage Rationale: I don't like rel. rel hoists the URL data type on the element pedestal and puts the role in an attribute. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 14:34:58 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03358 for ; Mon, 7 Feb 2005 14:34:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLeri053081; Mon, 7 Feb 2005 11:21:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JLeWU053080; Mon, 7 Feb 2005 11:21:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JLbwG053047 for ; Mon, 7 Feb 2005 11:21:39 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <4207B4FB.2000005@franklinmint.fm> References: <4207B4FB.2000005@franklinmint.fm> Date: Mon, 7 Feb 2005 11:21:34 -0800 To: Atom-Syntax From: Paul Hoffman Subject: Re: PaceFormatSecurity Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -1. If the current security documents that cover the material are insufficient, they should be fixed, and not have it listed in our document. We should only point to where generic information can be found and list things that are Atom-specific. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 14:39:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03954 for ; Mon, 7 Feb 2005 14:39:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JGSex052431; Mon, 7 Feb 2005 11:16:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JGSw0052429; Mon, 7 Feb 2005 11:16:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JGRAG052376; Mon, 7 Feb 2005 11:16:27 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54704 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228831AbVBGTQN (ORCPT + 1 other); Mon, 7 Feb 2005 21:16:13 +0200 In-Reply-To: References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom-Syntax From: Henri Sivonen Subject: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 21:15:56 +0200 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 19:50, Paul Hoffman wrote: > Even if you sent in a +1, 0, or -1 previously on a particular Pace, > send it in again. Hopefully, add a short or long comment on why you > feel it should or should not be considered part of the Atom core. -1 on PaceXhtmlNamespaceDiv The div is an additional container inside the Text construct container. The main purpose of the div is to save one for loop in a document-tree/pull-based client or, alternatively, to give a false sense of correctness in tag soup concatenation-based clients. IMO, neither rationale warrants a meaningless element inside a Text construct. (Noting that the Pace was retracted by the original author.) -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 14:42:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04105 for ; Mon, 7 Feb 2005 14:42:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JO0vK053398; Mon, 7 Feb 2005 11:24:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JO02R053397; Mon, 7 Feb 2005 11:24:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JNt1s053381 for ; Mon, 7 Feb 2005 11:23:59 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17JNmbp020559; Mon, 7 Feb 2005 14:23:50 -0500 (EST) Message-ID: <4207C023.3050504@intertwingly.net> Date: Mon, 07 Feb 2005 14:23:15 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood CC: Atom WG Subject: Re: PaceEntryOrder References: <4207AE39.7010507@franklinmint.fm> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Walter Underwood wrote: > --On February 7, 2005 1:06:49 PM -0500 Robert Sayre wrote: > >>Paul Hoffman wrote: >> >>>+1. It is a simple clarification that shows the intention without >>>restricting anyone. >> >>+1. Agree in full. > > -1. I don't see the benefit. Clients MAY re-order them, but that > doesn't mean they MUST ignore the order. The publisher may prefer > an order which cannot be expressed in the attributes. The Macintouch > and BBC New feeds cited before are good examples. I'm +1 on the Pace as written. I'd be equally +1 on a modifed Pace where "SHOULD NOT" was used in place of "MUST NOT". - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 14:45:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04385 for ; Mon, 7 Feb 2005 14:45:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JZv2S054675; Mon, 7 Feb 2005 11:35:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JZvXo054674; Mon, 7 Feb 2005 11:35:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JZuKT054663 for ; Mon, 7 Feb 2005 11:35:56 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17JZqkd026435; Mon, 7 Feb 2005 14:35:53 -0500 (EST) Message-ID: <4207C2F7.5080708@intertwingly.net> Date: Mon, 07 Feb 2005 14:35:19 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: Atom-Syntax Subject: Re: PaceFormatSecurity References: <4207B4FB.2000005@franklinmint.fm> In-Reply-To: <4207B4FB.2000005@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > -1. Covers HTML in too much detail, though it's still inadequate > coverage. This is isn't our problem. I blame the W3C :) I'm +1 on the pace, particularly now that the prescriptive text has been removed. It seems to me that we have an obligation to either (1) disallow HTML, or (2) mitigate allowing HTML by providing a security section such as this one. If (2) can be solved by reference, then that clearly would be preferred. But to date, no such reference has been found. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 14:51:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04954 for ; Mon, 7 Feb 2005 14:51:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JdWQC055236; Mon, 7 Feb 2005 11:39:32 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JdWNW055235; Mon, 7 Feb 2005 11:39:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JdVPs055222; Mon, 7 Feb 2005 11:39:31 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17JdLCi007256; Mon, 7 Feb 2005 14:39:22 -0500 (EST) Message-ID: <4207C3C8.6090307@intertwingly.net> Date: Mon, 07 Feb 2005 14:38:48 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Paul Hoffman , Atom-Syntax Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> In-Reply-To: <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > > On Feb 7, 2005, at 19:50, Paul Hoffman wrote: > >> Even if you sent in a +1, 0, or -1 previously on a particular Pace, >> send it in again. Hopefully, add a short or long comment on why you >> feel it should or should not be considered part of the Atom core. > > -1 on PaceXhtmlNamespaceDiv > > The div is an additional container inside the Text construct container. > The main purpose of the div is to save one for loop in a > document-tree/pull-based client or, alternatively, to give a false sense > of correctness in tag soup concatenation-based clients. IMO, neither > rationale warrants a meaningless element inside a Text construct. > > (Noting that the Pace was retracted by the original author.) It was retracted due to a perceived lack of interest - at that point it was a two party dialog between yourself and that author. Since then a number of folks (myself included) expressed support for this Pace, I reopened it with an email to the list, and I will now reiterate my support now with a +1. There are a number of issues that this resolves, such as whether the div element itself is to be considered part of the content in protocol POST methods. If they are not, you will tend over time to see multiple such wrappings. -Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 14:52:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05084 for ; Mon, 7 Feb 2005 14:52:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JgIY1055556; Mon, 7 Feb 2005 11:42:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JgIau055555; Mon, 7 Feb 2005 11:42:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JgHW8055544 for ; Mon, 7 Feb 2005 11:42:17 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207194212014003ie30e>; Mon, 7 Feb 2005 19:42:12 +0000 Date: Mon, 7 Feb 2005 12:42:10 -0700 Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <200502071904.COJ99627@ms8.netsolmail.com> Message-Id: <5B80F00A-7940-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, February 7, 2005, at 12:00 PM, Bob Wyman wrote: > In order to demonstrate polling at its most efficient, I defined and > convinced a number of folk to implement RFC3229+feed. This HTTP > extension > eliminates the problem with sending multiple copies of messages to > people > and the resulting drop in bandwidth requirements for those who poll > and use > RFC3229+feed was dramatic[1] -- however, the RFC3229+feed service still > consumes more bandwidth then the push service. Once again, this ain't > theory, it is experience. You are of course the one in a position to know about this. I'm curious though--do you have figures on how much push reduced bandwidth use vs. RFC3229+feed? My guess would be that the difference wouldn't be as dramatic as between feed and RFC3229+feed, but I recognize that I may be wrong. That guess is what I was expressing. >> I've lost track of what aspect of Atom's architecture you >> are saying is bound to polling at the expense of push. > There are several "Feed-oriented" or "polling oriented" discussions > going on: > 1. The requirement that feeds not be permitted to contain multiple > entries that have the same atom:id. This requirement prevents push > based > system from using feeds as "logs" or "histories" of messages sent. For > instance, at PubSub, the Atom file which is associated with every > subscription contains a stream of entries that are the entries that > either > were or would have been sent to the client if it had been connected. > The > first thing a client does on starting up is to read the Atom file in > order > to synchronize state with the server. Thus, the feed is actually just a > trace of the messages sent. This probably sounds weird if you're > feed-focused; however, it makes perfect sense if you are pushing > entries. It doesn't sound particularly weird, though I don't understand why the typical client would feel the need to see obsolete representations of entries that had been changed more than once while they were offline. I fully agree that we should not lock out the option of including multiple instances of an entry in some kind of Atom Document. But I also don't think that we should require all Atom Documents (other than Entry Documents) to do so. In other words, I don't think this is an either-or question--I think both should be possible. > 2. Significance of the order of entries in feeds. A push-fed client > only sees feeds in edge cases (like the PubSub synchronization usage > discussed above). Because a push-fed client receives a stream of > entries -- > not feeds, it can only see chronological order unless order is encoded > within the entry itself. Any requirement that document order is > significant > (and some are still suggesting it is) means that a push-based system > must > push entire feeds rather then individual entries. The bandwidth costs > of > doing so would be completely unacceptable. Agreed. > 3. The absence of a revision id or atom:modified. The feed-ists > don't see the need for revision numbers in part because they are > focused on > feeds rather than entries. If you live in the world of entries -- as a > push > system does -- then the need to distinguish multiple versions of the > same > entry becomes much, much more important. Makes sense. I personally have come to like the idea of using dc:modified rather than defining atom:modified. (I am a proponent of atom:updated because there is no Dublin Core equivalent for it). From owner-atom-syntax@mail.imc.org Mon Feb 7 14:52:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05102 for ; Mon, 7 Feb 2005 14:52:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JiAqf055790; Mon, 7 Feb 2005 11:44:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JiAeT055789; Mon, 7 Feb 2005 11:44:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JiANl055780 for ; Mon, 7 Feb 2005 11:44:10 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyEnj-0005fJ-6I for atom-syntax@imc.org; Mon, 07 Feb 2005 19:44:03 +0000 Message-ID: <4207C503.9000701@franklinmint.fm> Date: Mon, 07 Feb 2005 14:44:03 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceIconAndImage References: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1. should be exactly as it is in RSS, except with the recommendation that it should be 1:1, instead of size recomendations. There's also no reason to limit it to atom:head. is silly. should usher in the brave new world of HTML relations leaking into the Atom space. Alright. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 14:54:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05289 for ; Mon, 7 Feb 2005 14:54:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Jk3QO056005; Mon, 7 Feb 2005 11:46:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Jk3dq056004; Mon, 7 Feb 2005 11:46:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mcom.com (c3po.aoltw.net [64.236.137.25]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Jk2Cr055987 for ; Mon, 7 Feb 2005 11:46:02 -0800 (PST) (envelope-from jpanzer@aol.net) Received: from judge.mcom.com (judge.nscp.aoltw.net [10.169.8.47]) by mcom.com (8.10.0/8.10.0) with ESMTP id j17IJP403270 for ; Mon, 7 Feb 2005 10:19:25 -0800 (PST) Received: from [192.168.1.5] ([10.169.192.17]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id IBK08D00.X07 for ; Mon, 7 Feb 2005 10:19:25 -0800 Message-ID: <4207B12D.1010202@aol.net> Date: Mon, 07 Feb 2005 10:19:25 -0800 From: jpanzer@aol.net (John Panzer) User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom WG Subject: Re: PaceEntryOrder References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. Low cost, good benefits for interoperability. From owner-atom-syntax@mail.imc.org Mon Feb 7 15:05:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06351 for ; Mon, 7 Feb 2005 15:05:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Jqr5T057109; Mon, 7 Feb 2005 11:52:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JqrTX057108; Mon, 7 Feb 2005 11:52:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JqrDH057089 for ; Mon, 7 Feb 2005 11:52:53 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050207195245015009k2v6e>; Mon, 7 Feb 2005 19:52:46 +0000 Date: Mon, 7 Feb 2005 12:52:43 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceXhtmlNamespaceDiv From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, but I wouldn't object to a variant that required either the DIV with a namespace declaration OR for the namespace to be declared in or before . Examples of what I'd think was acceptable: ... This is bold OR This is bold OR
This is bold Here's what I think is just plain ugly and shouldn't be allowed: This is bold OR This is bold From owner-atom-syntax@mail.imc.org Mon Feb 7 15:10:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06963 for ; Mon, 7 Feb 2005 15:10:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17JxsbB057837; Mon, 7 Feb 2005 11:59:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17JxsaU057835; Mon, 7 Feb 2005 11:59:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Jxr1x057792; Mon, 7 Feb 2005 11:59:54 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17JwMUt024526; Mon, 7 Feb 2005 19:58:27 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom WG From: Graham Subject: Re: PaceEntryOrder Date: Mon, 7 Feb 2005 19:58:21 +0000 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, with the proviso that I think the first sentence is entirely meaningless. Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 15:10:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07034 for ; Mon, 7 Feb 2005 15:10:55 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K31QW058360; Mon, 7 Feb 2005 12:03:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K317j058359; Mon, 7 Feb 2005 12:03:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K30cQ058349 for ; Mon, 7 Feb 2005 12:03:00 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyF60-0005ra-2U for atom-syntax@imc.org; Mon, 07 Feb 2005 20:02:56 +0000 Message-ID: <4207C970.3050906@franklinmint.fm> Date: Mon, 07 Feb 2005 15:02:56 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: Atom-Syntax Subject: Re: PaceFormatSecurity References: <4207B4FB.2000005@franklinmint.fm> <4207C2F7.5080708@intertwingly.net> In-Reply-To: <4207C2F7.5080708@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > It seems to me that we have an obligation to either (1) disallow HTML, > or (2) mitigate allowing HTML by providing a security section such as > this one. > > If (2) can be solved by reference, then that clearly would be preferred. > But to date, no such reference has been found. So, engaging in bad specification practice[0] is the answer? HTML security is a problem for the W3C and/or an HTML-WG. Existing RFCs constitute the IETF's definition of adequate security coverage for HTML. If we want to change the status quo in our document, we need to say that we're updating those RFCs at the top of our document. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12625.html From owner-atom-syntax@mail.imc.org Mon Feb 7 15:11:01 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07054 for ; Mon, 7 Feb 2005 15:11:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K2dLG058282; Mon, 7 Feb 2005 12:02:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K2dPv058281; Mon, 7 Feb 2005 12:02:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K2cjA058270 for ; Mon, 7 Feb 2005 12:02:38 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17K1apM025428; Mon, 7 Feb 2005 20:01:36 GMT In-Reply-To: <4207B4FB.2000005@franklinmint.fm> References: <4207B4FB.2000005@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Atom-Syntax From: Graham Subject: Re: PaceFormatSecurity Date: Mon, 7 Feb 2005 20:01:35 +0000 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1, agree with Robert. Graham On 7 Feb 2005, at 6:35 pm, Robert Sayre wrote: > > -1. Covers HTML in too much detail, though it's still inadequate > coverage. This is isn't our problem. I blame the W3C :) > > Robert Sayre > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:14:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07673 for ; Mon, 7 Feb 2005 15:14:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K4jlx058562; Mon, 7 Feb 2005 12:04:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K4jnZ058561; Mon, 7 Feb 2005 12:04:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K4iK6058546; Mon, 7 Feb 2005 12:04:45 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17K3itn025911; Mon, 7 Feb 2005 20:03:44 GMT In-Reply-To: <4207C3C8.6090307@intertwingly.net> References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207C3C8.6090307@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Henri Sivonen , Paul Hoffman , Atom-Syntax From: Graham Subject: Re: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 20:03:43 +0000 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7 Feb 2005, at 7:38 pm, Sam Ruby wrote: > Since then a number of folks (myself included) expressed support for > this Pace, I reopened it with an email to the list, and I will now > reiterate my support now with a +1. > > There are a number of issues that this resolves, such as whether the > div element itself is to be considered part of the content in protocol > POST methods. If they are not, you will tend over time to see > multiple such wrappings. +1, and not just because it will make my life easier. Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 15:17:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07994 for ; Mon, 7 Feb 2005 15:17:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K9kcS059114; Mon, 7 Feb 2005 12:09:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K9k1p059113; Mon, 7 Feb 2005 12:09:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K9j2I059084 for ; Mon, 7 Feb 2005 12:09:45 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc12) with SMTP id <2005020720093901200g09bbe>; Mon, 7 Feb 2005 20:09:39 +0000 Date: Mon, 7 Feb 2005 13:09:37 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceCommentFeeds From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <313DD274-7944-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1: if not the whole Pace, then at least link/@rel="comments". From owner-atom-syntax@mail.imc.org Mon Feb 7 15:18:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08104 for ; Mon, 7 Feb 2005 15:18:08 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K8Sxc058961; Mon, 7 Feb 2005 12:08:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K8SA9058959; Mon, 7 Feb 2005 12:08:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K8QbG058907 for ; Mon, 7 Feb 2005 12:08:27 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 32032 invoked by uid 10); 7 Feb 2005 20:08:12 -0000 Received: (vexira-qq 32021-9377C477 invoked from network) 07 Feb 2005 21:08:12 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 20:08:12 -0000 Message-ID: <4207CAAB.30906@annevankesteren.nl> Date: Mon, 07 Feb 2005 21:08:11 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen CC: Paul Hoffman , Atom-Syntax Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> In-Reply-To: <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henri Sivonen wrote: > -1 on PaceXhtmlNamespaceDiv -1 from me as well. It is hack which might be useful for publishing systems (and perhaps aggregators) who do not use the right tools to generate a valid Atom file anyway. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 15:18:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08153 for ; Mon, 7 Feb 2005 15:18:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K8Stl058970; Mon, 7 Feb 2005 12:08:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K8SVl058969; Mon, 7 Feb 2005 12:08:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K8SwC058941 for ; Mon, 7 Feb 2005 12:08:28 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020720082201100cga9ue>; Mon, 7 Feb 2005 20:08:23 +0000 Date: Mon, 7 Feb 2005 13:08:21 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceFeedRecursive From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <03CEAE2D-7944-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1: recursion is too complex and bulky. But we could (should?) specify lack of recursion in terms of particular types of Atom Documents or particular profiles, leaving the door open for extensions to define document types that allow recursion. From owner-atom-syntax@mail.imc.org Mon Feb 7 15:18:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08205 for ; Mon, 7 Feb 2005 15:18:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K93kl059027; Mon, 7 Feb 2005 12:09:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K93xn059026; Mon, 7 Feb 2005 12:09:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K92k1059010 for ; Mon, 7 Feb 2005 12:09:02 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020720085601100cl309e>; Mon, 7 Feb 2005 20:08:57 +0000 Date: Mon, 7 Feb 2005 13:08:54 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceEntriesElement From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <17D94264-7944-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1: recursion is too complex and bulky. From owner-atom-syntax@mail.imc.org Mon Feb 7 15:18:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08233 for ; Mon, 7 Feb 2005 15:18:26 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KA8lk059166; Mon, 7 Feb 2005 12:10:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KA8Nr059165; Mon, 7 Feb 2005 12:10:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KA66n059148 for ; Mon, 7 Feb 2005 12:10:07 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 23814 invoked by uid 10); 7 Feb 2005 20:10:00 -0000 Received: (vexira-qq 23804-66B41B32 invoked from network) 07 Feb 2005 21:10:00 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 20:10:00 -0000 Message-ID: <4207CB17.3030607@annevankesteren.nl> Date: Mon, 07 Feb 2005 21:09:59 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceRemoveVersionAttr References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Antone Roundy wrote: > +1. I'd like to see language specifying how the namespace can be used > to determine compatibility between revisions of the specification--ie. > any app that can handle one version of Atom can handle any version > sharing the same namespace, and any feed that's valid under any version > of Atom is valid under any version sharing the same namespace. +1. I totally agree with the above. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 15:19:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08391 for ; Mon, 7 Feb 2005 15:19:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KBS4G059287; Mon, 7 Feb 2005 12:11:28 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KBSIr059286; Mon, 7 Feb 2005 12:11:28 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KBRcZ059263 for ; Mon, 7 Feb 2005 12:11:27 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 59397 invoked by uid 17064); 7 Feb 2005 20:11:17 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 20:11:17 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <705fc547748c3188d295ff7b46288a9c@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceArchiveDocument posted Date: Mon, 7 Feb 2005 21:10:53 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 your archive document already. HELLO GUYS/GALS YOU ARE THERE AT THE FINISH LINE. IT ALL WORKS! One of the arguments against the sliding window view in the historical state of entries is that it was too complicated. But clearly not going that way is making things WAY MORE COMPLICATED. So before proceeding any further it may be worth now comparing the complexity of both proposals in detail. My guess is that the historical one is just a little surprising, but that is all. Henry Story From owner-atom-syntax@mail.imc.org Mon Feb 7 15:19:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08392 for ; Mon, 7 Feb 2005 15:19:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K9iLQ059098; Mon, 7 Feb 2005 12:09:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K9iCu059097; Mon, 7 Feb 2005 12:09:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K9hSv059073 for ; Mon, 7 Feb 2005 12:09:43 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54735 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228818AbVBGUJ3 (ORCPT ); Mon, 7 Feb 2005 22:09:29 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2e5e40991a5233dcec4017418624be14@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 22:09:28 +0200 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 21:52, Antone Roundy wrote: > +1, but I wouldn't object to a variant that required either the DIV > with a namespace declaration OR for the namespace to be declared in > or before . Examples of what I'd think was > acceptable: > > > ... > This is bold This is against the Pace. Are you really supporting the pace? > OR > > This is bold This is against the Pace, too. > OR > >
This is bold This one is against the pace as well. Also, the 'b' element would be in the same namespace as 'content', which seems wrong. > Here's what I think is just plain ugly and shouldn't be allowed: > > This is bold IMO, that should be allowed. Atom has no business in restricting the syntactic sugar provided by Namespaces in XML. > OR > > This is bold IMO, this on should be allowed on the same grounds. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 15:20:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08485 for ; Mon, 7 Feb 2005 15:20:09 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K63NI058729; Mon, 7 Feb 2005 12:06:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17K63LY058728; Mon, 7 Feb 2005 12:06:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17K63cL058712 for ; Mon, 7 Feb 2005 12:06:03 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020720055701100chk64e>; Mon, 7 Feb 2005 20:05:57 +0000 Date: Mon, 7 Feb 2005 13:05:55 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceRemoveVersionAttr From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. I'd like to see language specifying how the namespace can be used to determine compatibility between revisions of the specification--ie. any app that can handle one version of Atom can handle any version sharing the same namespace, and any feed that's valid under any version of Atom is valid under any version sharing the same namespace. From owner-atom-syntax@mail.imc.org Mon Feb 7 15:21:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08910 for ; Mon, 7 Feb 2005 15:21:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KCtpb059468; Mon, 7 Feb 2005 12:12:55 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KCtus059467; Mon, 7 Feb 2005 12:12:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KCmn5059442 for ; Mon, 7 Feb 2005 12:12:54 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17KBogB028224; Mon, 7 Feb 2005 20:11:56 GMT In-Reply-To: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> References: <99205074-793B-11D9-88AE-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <95269134fcbc507d551146803a538f66@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Graham Subject: Re: PaceIconAndImage Date: Mon, 7 Feb 2005 20:11:49 +0000 To: Antone Roundy X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1, agree with renaming image to logo. Disagree with allowing either in entry, since their are already one million ways to do that (HTML, content@src, etc). Graham On 7 Feb 2005, at 7:08 pm, Antone Roundy wrote: > > +1 if is changed to or, even better, if is > allowed in . I don't care whether is allowed in entry, > though I see no reason not to allow it. > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:25:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09381 for ; Mon, 7 Feb 2005 15:25:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KGFox060601; Mon, 7 Feb 2005 12:16:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KGFvM060600; Mon, 7 Feb 2005 12:16:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KGEnE060594 for ; Mon, 7 Feb 2005 12:16:14 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 63071 invoked by uid 17064); 7 Feb 2005 20:16:14 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 20:16:14 -0000 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <828ab1635f9286d37db80cbb708bd84e@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Antone Roundy From: Henry Story Subject: Re: PaceArchiveDocument posted Date: Mon, 7 Feb 2005 21:15:51 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 in your feed. The spec allows you to remove all the old versions if you wish. After all the Present time, is just one element in the sequence of history. People who only want to live in the present don't negate history. They just don't remember it. Henry Story From owner-atom-syntax@mail.imc.org Mon Feb 7 15:27:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09630 for ; Mon, 7 Feb 2005 15:27:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KJ9Sp060914; Mon, 7 Feb 2005 12:19:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KJ9Xd060913; Mon, 7 Feb 2005 12:19:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KJ7DD060893 for ; Mon, 7 Feb 2005 12:19:08 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1570473wra for ; Mon, 07 Feb 2005 12:19:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=R9DveLSqnpPeiayNFP9SB8cUpVszwpyHJN9bH5+ebLUQkWCgkZ4IBleYjtMBeYkMZG2/i+0xIyEzDRNo8YMhEeqOLaXHBuI6pd5gMaQdnOTlvwB6bftGrSjLaigRQu3CgwCAK1xRg+ywQ/nsb/xoUQbTp8kwmF0ltSH50YpMhBo= Received: by 10.54.43.11 with SMTP id q11mr229533wrq; Mon, 07 Feb 2005 12:19:00 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 44sm6432wri.2005.02.07.12.19.00; Mon, 07 Feb 2005 12:19:00 -0800 (PST) Message-ID: <4207CD2C.4090608@gmail.com> Date: Mon, 07 Feb 2005 12:18:52 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ok, now that I'm thinking about this more, I'm changing my initial +0 to +1. This just makes sense. There does need to be a container for the XHTML and div is a solid, logical choice. I don't think it should matter where the xmlns is declared... any ancestor element will do. - James M Snell Antone Roundy wrote: > > +1, but I wouldn't object to a variant that required either the DIV with > a namespace declaration OR for the namespace to be declared in > or before . Examples of what I'd think was acceptable: > > > ... > This is bold > > OR > > This is bold > > OR > >
This is bold > > > Here's what I think is just plain ugly and shouldn't be allowed: > > This is bold > > OR > > This is bold > > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:29:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09918 for ; Mon, 7 Feb 2005 15:29:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KJMpc060934; Mon, 7 Feb 2005 12:19:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KJMNF060933; Mon, 7 Feb 2005 12:19:22 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KJLLd060927 for ; Mon, 7 Feb 2005 12:19:21 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 64756 invoked by uid 17064); 7 Feb 2005 20:19:21 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 20:19:21 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33109ec8db1d1715f291b1d28c68508f@bblfish.net> Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceFeedRecursive Date: Mon, 7 Feb 2005 21:18:58 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 19 Jan 2005, at 10:38, Henry Story wrote: > I think the easiest way to get what you want is a 2 step procedure: > > 1. Merge the Head with the Entry constructs. They are not different > enough > for the difference to be important. > 2. Make a Feed a subclass of Entry, with the extra property of being > able > to point to a Entry (Since a Feed is a Entry, it also points to > other Feeds) > > I am +1 on such a refactoring. Nothing will be lost doing this, and a > lot gained > in simplicity. > > Henry I now no longer believe 2. Is needed. 1 would be quite neat though. Henry From owner-atom-syntax@mail.imc.org Mon Feb 7 15:32:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10199 for ; Mon, 7 Feb 2005 15:32:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KOJ33061566; Mon, 7 Feb 2005 12:24:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KOJNC061565; Mon, 7 Feb 2005 12:24:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KOHY9061559; Mon, 7 Feb 2005 12:24:18 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4207AE39.7010507@franklinmint.fm> Date: Mon, 7 Feb 2005 12:24:15 -0800 To: Walter Underwood , Atom WG From: Paul Hoffman Subject: Re: PaceEntryOrder Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:07 AM -0800 2/7/05, Walter Underwood wrote: >-1. I don't see the benefit. Clients MAY re-order them, but that >doesn't mean they MUST ignore the order. The publisher may prefer >an order which cannot be expressed in the attributes. The Macintouch >and BBC New feeds cited before are good examples. I'm very confused. Clients that show the entries of those feeds in the received order are perfectly acceptable according to the wording of this Pace. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 15:34:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10446 for ; Mon, 7 Feb 2005 15:34:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KR8UF061894; Mon, 7 Feb 2005 12:27:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KR8Bs061893; Mon, 7 Feb 2005 12:27:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KR7ZY061879 for ; Mon, 7 Feb 2005 12:27:08 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54769 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228821AbVBGU1C (ORCPT ); Mon, 7 Feb 2005 22:27:02 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <4207AD97.8020504@franklinmint.fm> References: <4207AD97.8020504@franklinmint.fm> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63bb6c99f260c9ca1724c23e5b54c341@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: PaceArchiveDocument Date: Mon, 7 Feb 2005 22:27:01 +0200 To: Atom WG X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 15:35:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10618 for ; Mon, 7 Feb 2005 15:35:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KPhZk061739; Mon, 7 Feb 2005 12:25:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KPhDO061738; Mon, 7 Feb 2005 12:25:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KPfBj061729 for ; Mon, 7 Feb 2005 12:25:42 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 24078 invoked by uid 10); 7 Feb 2005 20:25:36 -0000 Received: (vexira-qq 24054-4E3F4FD7 invoked from network) 07 Feb 2005 21:25:36 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 20:25:36 -0000 Message-ID: <4207CEBF.10206@annevankesteren.nl> Date: Mon, 07 Feb 2005 21:25:35 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> In-Reply-To: <4207CD2C.4090608@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > > Ok, now that I'm thinking about this more, I'm changing my initial +0 to > +1. This just makes sense. There does need to be a container for the > XHTML and div is a solid, logical choice. I don't think it should > matter where the xmlns is declared... any ancestor element will do. I'm still -1. But I was wondering, why only ancestor elements? Wouldn't the most logical thing for "string based generators" be to apply it on the DIV element? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 15:37:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11068 for ; Mon, 7 Feb 2005 15:37:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KSeoV062091; Mon, 7 Feb 2005 12:28:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KSeqW062090; Mon, 7 Feb 2005 12:28:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KSeZV062084 for ; Mon, 7 Feb 2005 12:28:40 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 72875 invoked by uid 17064); 7 Feb 2005 20:28:40 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.6.132]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 7 Feb 2005 20:28:40 -0000 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <17D94264-7944-11D9-88AE-003065EA6144@geckotribe.com> References: <17D94264-7944-11D9-88AE-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Henry Story Subject: Re: PaceEntriesElement Date: Mon, 7 Feb 2005 21:28:16 +0100 To: Atom Syntax X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 I agree. Recursion can be placed in the model. It does not need to be in the syntax. In any case this is too big a change too late in the game. Henry On 7 Feb 2005, at 21:08, Antone Roundy wrote: > > -1: recursion is too complex and bulky. > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:38:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11182 for ; Mon, 7 Feb 2005 15:38:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KSFcH062022; Mon, 7 Feb 2005 12:28:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KSFGW062021; Mon, 7 Feb 2005 12:28:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KSFYh061999 for ; Mon, 7 Feb 2005 12:28:15 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54774 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228688AbVBGU2J (ORCPT ); Mon, 7 Feb 2005 22:28:09 +0200 In-Reply-To: <4207CD2C.4090608@gmail.com> References: <4207CD2C.4090608@gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <63afc91de93d8952e7e83fc8d92097d1@iki.fi> Content-Transfer-Encoding: 7bit Cc: Antone Roundy , atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 22:28:08 +0200 To: jasnell@gmail.com X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 22:18, James M Snell wrote: > There does need to be a container for the XHTML and div is a solid, > logical choice. The container is the Atom Text construct itself! -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 15:46:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12262 for ; Mon, 7 Feb 2005 15:46:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Ka46Y062796; Mon, 7 Feb 2005 12:36:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Ka4NR062795; Mon, 7 Feb 2005 12:36:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Ka3aL062782 for ; Mon, 7 Feb 2005 12:36:03 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so1143065wri for ; Mon, 07 Feb 2005 12:35:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=siRnue/7lu/0zzLbDt5Z0iVItPfiNQwU2WDuzur1RCJyCkEA4t3P4CCYJtJVGyn+DeQn6MVgVCzaFFNZNDi1ex2G6leb6q1wShbaC7lgBnsgmNj6rV7lh17oKV1rK29IE9y0NyncND7JlhKY3NNTGBG6+U5RDi2dY7E0cBBUwIQ= Received: by 10.54.56.28 with SMTP id e28mr307098wra; Mon, 07 Feb 2005 12:35:57 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 35sm63812wra.2005.02.07.12.35.56; Mon, 07 Feb 2005 12:35:57 -0800 (PST) Message-ID: <4207D125.6090407@gmail.com> Date: Mon, 07 Feb 2005 12:35:49 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> In-Reply-To: <4207CEBF.10206@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, sorry I wasn't clear. Not *only* on ancestor elements. any of the following cases should be allowed. - James M Snell Anne van Kesteren wrote: > James M Snell wrote: > >> >> Ok, now that I'm thinking about this more, I'm changing my initial +0 >> to +1. This just makes sense. There does need to be a container for >> the XHTML and div is a solid, logical choice. I don't think it should >> matter where the xmlns is declared... any ancestor element will do. > > > I'm still -1. But I was wondering, why only ancestor elements? Wouldn't > the most logical thing for "string based generators" be to apply it on > the DIV element? > > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:47:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12423 for ; Mon, 7 Feb 2005 15:47:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KdLCb063080; Mon, 7 Feb 2005 12:39:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KdL2O063079; Mon, 7 Feb 2005 12:39:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KdKbb063069 for ; Mon, 7 Feb 2005 12:39:20 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 1049 invoked by uid 10); 7 Feb 2005 20:39:14 -0000 Received: (vexira-qq 01033-FA85D940 invoked from network) 07 Feb 2005 21:39:14 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 20:39:14 -0000 Message-ID: <4207D1F2.307@annevankesteren.nl> Date: Mon, 07 Feb 2005 21:39:14 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D125.6090407@gmail.com> In-Reply-To: <4207D125.6090407@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > > Yes, sorry I wasn't clear. Not *only* on ancestor elements. any of the > following cases should be allowed. > > [snip] And surely |
| so people who append strings together can do so easily. I still wonder what the advantage of this conainer is. Especially since, as pointed out, the CONTENT element already is the container. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 15:53:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13394 for ; Mon, 7 Feb 2005 15:53:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Kj27Y063670; Mon, 7 Feb 2005 12:45:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Kj272063669; Mon, 7 Feb 2005 12:45:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Kj1HO063655 for ; Mon, 7 Feb 2005 12:45:01 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1645289wri for ; Mon, 07 Feb 2005 12:44:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LeOxk1FzFaikpsTvTfKWcqiye/yQoR/heyMIHFFWQWY7xswu6BiblCcoauWGvIIybjLwlYWXLyGl37AAwDTD8W0uu0LhopXFnj/iVJqNGmadinT7RHKeFQlWCkmDMoTpgN2n76JQ6qfh0bHT9HzSH2fWQ8OEMtSufUP/mrrPbtM= Received: by 10.54.51.11 with SMTP id y11mr34400wry; Mon, 07 Feb 2005 12:44:56 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id d8sm5132wra.2005.02.07.12.44.54; Mon, 07 Feb 2005 12:44:56 -0800 (PST) Message-ID: <4207D33F.7000504@gmail.com> Date: Mon, 07 Feb 2005 12:44:47 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Henri Sivonen , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <63afc91de93d8952e7e83fc8d92097d1@iki.fi> In-Reply-To: <63afc91de93d8952e7e83fc8d92097d1@iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Nah, I don't buy it. XHTML is just a special case of an XML content and if we were embedding some XML data (say an atom:feed) it wouldn't make any sense (under the assumption that the element is top level container) for us to do: ... ... In my opinion, the XML contained in the content or text element should be capable of standing alone outside of the content element as a well-formed document and XHTML is just a special case of XML content. - James M Snell Henri Sivonen wrote: > On Feb 7, 2005, at 22:18, James M Snell wrote: > >> There does need to be a container for the XHTML and div is a solid, >> logical choice. > > > The container is the Atom Text construct itself! > From owner-atom-syntax@mail.imc.org Mon Feb 7 15:56:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13951 for ; Mon, 7 Feb 2005 15:56:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KjnAo063729; Mon, 7 Feb 2005 12:45:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KjnBt063728; Mon, 7 Feb 2005 12:45:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KjmTk063719 for ; Mon, 7 Feb 2005 12:45:48 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050207204543016004n0t7e>; Mon, 7 Feb 2005 20:45:43 +0000 Date: Mon, 7 Feb 2005 13:45:41 -0700 Subject: Re: PaceXhtmlNamespaceDiv Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <2e5e40991a5233dcec4017418624be14@iki.fi> Message-Id: <3B06B986-7949-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Monday, February 7, 2005, at 01:09 PM, Henri Sivonen wrote: > On Feb 7, 2005, at 21:52, Antone Roundy wrote: >> +1, but I wouldn't object to a variant that required either the DIV >> with a namespace declaration OR for the namespace to be declared in >> or before . Examples of what I'd think was >> acceptable: >> >> >> ... >> This is bold > > This is against the Pace. Are you really supporting the pace? Yes, while saying that I would be satisfied with this too--as long as the namespace declaration doesn't occur inside unless in a DIV that contains everything else that's in . >> OR >> >> This is bold > > This is against the Pace, too. Yep. Same answer. >> OR >> >>
This is bold > > This one is against the pace as well. Also, the 'b' element would be > in the same namespace as 'content', which seems wrong. Gaah! I left off the
and accidentally put a "/" in the end of the
tag. I meant
This is bold
. One of those mistakes I could understand, but how did I manage to do both at once? From owner-atom-syntax@mail.imc.org Mon Feb 7 16:00:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14593 for ; Mon, 7 Feb 2005 16:00:04 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KomBT064277; Mon, 7 Feb 2005 12:50:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Kom3w064276; Mon, 7 Feb 2005 12:50:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KolhM064266 for ; Mon, 7 Feb 2005 12:50:47 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54792 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228761AbVBGUul (ORCPT ); Mon, 7 Feb 2005 22:50:41 +0200 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <4207D1F2.307@annevankesteren.nl> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D125.6090407@gmail.com> <4207D1F2.307@annevankesteren.nl> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <4054431a15aa236616c5b33f4237abf8@iki.fi> Content-Transfer-Encoding: 7bit From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 22:50:40 +0200 To: Atom WG X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit For the record, the additional loop that the div would save in a DOM-based client is not that hard: copyLangAndBase(atomTextCostruct, targetDivInTemplate); for (Node n = atomTextCostruct.getFirstChild(); n != null; n = n.getNextSibling()) { targetDivInTemplate.appendChild(templateXhtmlDocument.importNode(n, true)); } Is that too much to ask from clients? -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 16:00:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14652 for ; Mon, 7 Feb 2005 16:00:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KpTuq064344; Mon, 7 Feb 2005 12:51:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17KpTrg064343; Mon, 7 Feb 2005 12:51:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KpSxC064334 for ; Mon, 7 Feb 2005 12:51:28 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 4717 invoked by uid 10); 7 Feb 2005 20:51:23 -0000 Received: (vexira-qq 04711-D301AA68 invoked from network) 07 Feb 2005 21:51:22 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 20:51:22 -0000 Message-ID: <4207D4CA.5070909@annevankesteren.nl> Date: Mon, 07 Feb 2005 21:51:22 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: Henri Sivonen , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <63afc91de93d8952e7e83fc8d92097d1@iki.fi> <4207D33F.7000504@gmail.com> In-Reply-To: <4207D33F.7000504@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > Nah, I don't buy it. XHTML is just a special case of an XML content and > if we were embedding some XML data (say an atom:feed) it wouldn't make > any sense (under the assumption that the element is top > level container) for us to do: > > > > ... > > > ... > > I do not follow this example. > In my opinion, the XML contained in the content or text element should > be capable of standing alone outside of the content element as a > well-formed document and XHTML is just a special case of XML content. So you want a DIV as wrapper element for TITLE and similar elements as well? -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 16:10:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17623 for ; Mon, 7 Feb 2005 16:10:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KwfOX065031; Mon, 7 Feb 2005 12:58:41 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Kwfi3065030; Mon, 7 Feb 2005 12:58:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17KweW2065019 for ; Mon, 7 Feb 2005 12:58:41 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17KwZbp029763; Mon, 7 Feb 2005 15:58:36 -0500 (EST) Message-ID: <4207D659.7010909@intertwingly.net> Date: Mon, 07 Feb 2005 15:58:01 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> In-Reply-To: <4207CEBF.10206@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > James M Snell wrote: > >> Ok, now that I'm thinking about this more, I'm changing my initial +0 >> to +1. This just makes sense. There does need to be a container for >> the XHTML and div is a solid, logical choice. I don't think it should >> matter where the xmlns is declared... any ancestor element will do. > > I'm still -1. But I was wondering, why only ancestor elements? Wouldn't > the most logical thing for "string based generators" be to apply it on > the DIV element? I'm confused. If you are opposed to this pace, then what div element? It may also be helpful to look at a specific feed, for example this one: http://www.imc.org/atom-syntax/mail-archive/msg12902.html Experiment with alternate serializations if you like. The important question is whether the
element is part of the format or part of the content? Should aggregators copy it? When an Atom entry is POSTed to a blog, is the div part of the content? - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 16:10:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17760 for ; Mon, 7 Feb 2005 16:10:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L1spk065427; Mon, 7 Feb 2005 13:01:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17L1sVD065426; Mon, 7 Feb 2005 13:01:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp1.versatel.nl (smtp1.versatel.nl [62.58.50.88]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L1pfl065389 for ; Mon, 7 Feb 2005 13:01:53 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 29425 invoked by uid 10); 7 Feb 2005 21:01:43 -0000 Received: (vexira-qq 29400-5AD53C88 invoked from network) 07 Feb 2005 22:01:42 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp1.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 7 Feb 2005 21:01:42 -0000 Message-ID: <4207D735.6080809@annevankesteren.nl> Date: Mon, 07 Feb 2005 22:01:41 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> In-Reply-To: <4207D659.7010909@intertwingly.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode01.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: >>> Ok, now that I'm thinking about this more, I'm changing my initial +0 >>> to +1. This just makes sense. There does need to be a container for >>> the XHTML and div is a solid, logical choice. I don't think it >>> should matter where the xmlns is declared... any ancestor element >>> will do. >> >> I'm still -1. But I was wondering, why only ancestor elements? >> Wouldn't the most logical thing for "string based generators" be to >> apply it on the DIV element? > > I'm confused. If you are opposed to this pace, then what div element? That was a question in reply to what James wrote. It appeared to be an error. > It may also be helpful to look at a specific feed, for example this one: > > http://www.imc.org/atom-syntax/mail-archive/msg12902.html > > Experiment with alternate serializations if you like. > > The important question is whether the
element is part of the > format or part of the content? Should aggregators copy it? When an > Atom entry is POSTed to a blog, is the div part of the content? If the page is adopted, which I hope not, it MUST NOT be part of the content. If the page is not adopted it MUST be part of the content. -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Mon Feb 7 16:11:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18100 for ; Mon, 7 Feb 2005 16:11:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Kxo1k065168; Mon, 7 Feb 2005 12:59:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Kxobr065167; Mon, 7 Feb 2005 12:59:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Kxn2V065154 for ; Mon, 7 Feb 2005 12:59:49 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1583616wra for ; Mon, 07 Feb 2005 12:59:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=AlJsaaNeWjz1mQHbNDCHpl/CcGmRaAHmtdhCy19ZExzo+1sKrjpGaYJlU9Fiqvad/B1goGJKdAfd7FTmbYCTqoRv5qkxNIUWmWqWBukm7tajWEkTZ8EzXJIeESNWE5qQ6VpMHcvgsZCZFjn3ALYJLCAbscdoFPJDGEpj64pp4Wg= Received: by 10.54.48.33 with SMTP id v33mr152457wrv; Mon, 07 Feb 2005 12:59:44 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id d6sm101283wra.2005.02.07.12.59.43; Mon, 07 Feb 2005 12:59:44 -0800 (PST) Message-ID: <4207D6B3.5080606@gmail.com> Date: Mon, 07 Feb 2005 12:59:31 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <63afc91de93d8952e7e83fc8d92097d1@iki.fi> <4207D33F.7000504@gmail.com> <4207D4CA.5070909@annevankesteren.nl> In-Reply-To: <4207D4CA.5070909@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > James M Snell wrote: > >> Nah, I don't buy it. XHTML is just a special case of an XML content >> and if we were embedding some XML data (say an atom:feed) it wouldn't >> make any sense (under the assumption that the element is >> top level container) for us to do: >> >> >> >> ... >> >> >> ... >> >> > > > I do not follow this example. > The point is that should not be viewed as the root element for contained XML. The XML content should be able to stand on it's own, indepedently of the content or text construct element as well-formed XML. > >> In my opinion, the XML contained in the content or text element should >> be capable of standing alone outside of the content element as a >> well-formed document and XHTML is just a special case of XML content. > > > So you want a DIV as wrapper element for TITLE and similar elements as > well? > > For Text construct and Content, if XHTML is used, there should be a DIV. If someone wants to use XHTML for title, then yes, they should use a DIV. Otherwise, they can use plain text. - James M Snell From owner-atom-syntax@mail.imc.org Mon Feb 7 16:13:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18802 for ; Mon, 7 Feb 2005 16:13:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L3VST065616; Mon, 7 Feb 2005 13:03:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17L3Vc5065615; Mon, 7 Feb 2005 13:03:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L3UGA065594 for ; Mon, 7 Feb 2005 13:03:30 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207210325014003i70oe>; Mon, 7 Feb 2005 21:03:25 +0000 Date: Mon, 7 Feb 2005 14:03:24 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceProfileAttribute From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1: One profile (or maybe set of profiles) per document is better in my opinion. If an aggregator aggregates entries with different profiles, it can either fix them up as needed to conform to a common profile, or if multiple profiles can be specified at the top level, declare the profiles for all of the entries in the document there. From owner-atom-syntax@mail.imc.org Mon Feb 7 16:19:03 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20537 for ; Mon, 7 Feb 2005 16:19:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L81No066100; Mon, 7 Feb 2005 13:08:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17L81oq066099; Mon, 7 Feb 2005 13:08:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17L80Qv066084 for ; Mon, 7 Feb 2005 13:08:00 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54798 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228836AbVBGVHy (ORCPT ); Mon, 7 Feb 2005 23:07:54 +0200 In-Reply-To: <4207D33F.7000504@gmail.com> References: <4207CD2C.4090608@gmail.com> <63afc91de93d8952e7e83fc8d92097d1@iki.fi> <4207D33F.7000504@gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1db55def07443731d1b9b978f97b808d@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Mon, 7 Feb 2005 23:07:53 +0200 To: jasnell@gmail.com X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 22:44, James M Snell wrote: > > Nah, I don't buy it. XHTML is just a special case of an XML content Atom has chosen to treat type='XHTML' (as opposed to type='application/xtml+xml') as a special case. > wouldn't make any sense (under the assumption that the > element is top level container) for us to do: > > > > ... > > > ... > > By that logic, you'd have to include the 'html', 'head', 'title' and 'body' XHTML elements as well. See http://macsanomat.com/atom for an example of that. (0.3 was silent on subsetting the XHTML document, so logically I had to assume it was not allowed, although the ViewSourceClan thought it was.) -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Mon Feb 7 16:25:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22219 for ; Mon, 7 Feb 2005 16:25:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LHNlZ067143; Mon, 7 Feb 2005 13:17:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LHN66067142; Mon, 7 Feb 2005 13:17:23 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LHMtB067120 for ; Mon, 7 Feb 2005 13:17:22 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050207211717015009f6bae>; Mon, 7 Feb 2005 21:17:17 +0000 Date: Mon, 7 Feb 2005 14:17:15 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceRepeatIdInDocument From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 (yeah, I know I'm the author) if we define some way to create what I've recently referred to as Archive Documents. My preferred method is based on PaceProfile (more on that to come). From owner-atom-syntax@mail.imc.org Mon Feb 7 16:28:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22360 for ; Mon, 7 Feb 2005 16:28:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LHEEG067115; Mon, 7 Feb 2005 13:17:14 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LHENf067114; Mon, 7 Feb 2005 13:17:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LHDor067100 for ; Mon, 7 Feb 2005 13:17:14 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1589313wra for ; Mon, 07 Feb 2005 13:17:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=G2phIkYThVZl9oIBHnrhQi5tEX5Y/Bnx/NxJ77y7KxbinFfUcQj/2Taf0Nj/+hOXUv55YjUTrVYBKjtKCL0QGBoSyoQTGzZ0VVTstFWJ8utEFAtHBYwveE3HCYNbeJtbaOrloHFbZMQT6H9wSJRsC7TWh1NHWQFG9VL/AneIi10= Received: by 10.54.54.71 with SMTP id c71mr328016wra; Mon, 07 Feb 2005 13:17:07 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 34sm155484wra.2005.02.07.13.17.07; Mon, 07 Feb 2005 13:17:07 -0800 (PST) Message-ID: <4207DACD.7090007@gmail.com> Date: Mon, 07 Feb 2005 13:17:01 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy , atom-syntax@imc.org Subject: Re: PaceProfileAttribute References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This is entirely possible also. Just to be clear tho, you're not -1'ing the idea of profiles, just the allowing of the @profile attribute on sub-elements (e.g. entries contained in feeds) correct? This is an important distinction because I'm definitely not married to the syntax as presented but would definitely like to see us adopt the profile mechanism in general. - James M Snell Antone Roundy wrote: > > -1: One profile (or maybe set of profiles) per document is better in my > opinion. If an aggregator aggregates entries with different profiles, > it can either fix them up as needed to conform to a common profile, or > if multiple profiles can be specified at the top level, declare the > profiles for all of the entries in the document there. > > From owner-atom-syntax@mail.imc.org Mon Feb 7 16:28:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22394 for ; Mon, 7 Feb 2005 16:28:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LEdWI066761; Mon, 7 Feb 2005 13:14:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LEdbu066760; Mon, 7 Feb 2005 13:14:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LEcOl066706 for ; Mon, 7 Feb 2005 13:14:38 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta06-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050207211422.TNQO8887.mta08-winn.mailhost.ntl.com@aamta06-winn.mailhost.ntl.com>; Mon, 7 Feb 2005 21:14:22 +0000 Received: from cpc3-stke1-5-0-cust2.bagu.cable.ntl.com ([82.11.128.2]) by aamta06-winn.mailhost.ntl.com with ESMTP id <20050207211422.HDOL1438.aamta06-winn.mailhost.ntl.com@cpc3-stke1-5-0-cust2.bagu.cable.ntl.com>; Mon, 7 Feb 2005 21:14:22 +0000 Date: Mon, 7 Feb 2005 21:14:28 +0000 From: David Powell X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <1759188609.20050207211428@djpowell.net> To: Sam Ruby CC: Walter Underwood , Atom WG Subject: Re: PaceEntryOrder In-Reply-To: <4207C023.3050504@intertwingly.net> References: <4207AE39.7010507@franklinmint.fm> <4207C023.3050504@intertwingly.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Monday, February 7, 2005, 7:23:15 PM, you wrote: > I'm +1 on the Pace as written. I'd be equally +1 on a modifed Pace > where "SHOULD NOT" was used in place of "MUST NOT". Sam, have you misread the Pace? The only occurrence of "MUST NOT" is in the Rationale, where it has been copied from Atom 0.3 as an example. The proposal is to add the following paragraph: This specification assigns no significance to the order of atom:entry elements within the feed. Processors MAY present entries in a different order to which they are appear in an Atom Feed Document. Also, Walter's comment seems to suggest the same confusion: > -1. I don't see the benefit. Clients MAY re-order them, but that > doesn't mean they MUST ignore the order. The publisher may prefer an > order which cannot be expressed in the attributes. The Macintouch > and BBC New feeds cited before are good examples. I'll try to be a bit more conservative with the PRE tags in future :) -- Dave From owner-atom-syntax@mail.imc.org Mon Feb 7 16:29:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22541 for ; Mon, 7 Feb 2005 16:29:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LMVC0067824; Mon, 7 Feb 2005 13:22:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LMVqt067823; Mon, 7 Feb 2005 13:22:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LMUhO067799 for ; Mon, 7 Feb 2005 13:22:30 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17LMPCi006365; Mon, 7 Feb 2005 16:22:26 -0500 (EST) Message-ID: <4207DBF0.60308@intertwingly.net> Date: Mon, 07 Feb 2005 16:21:52 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> In-Reply-To: <4207D735.6080809@annevankesteren.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > Sam Ruby wrote: > >>>> Ok, now that I'm thinking about this more, I'm changing my initial >>>> +0 to +1. This just makes sense. There does need to be a container >>>> for the XHTML and div is a solid, logical choice. I don't think it >>>> should matter where the xmlns is declared... any ancestor element >>>> will do. >>> >>> >>> I'm still -1. But I was wondering, why only ancestor elements? >>> Wouldn't the most logical thing for "string based generators" be to >>> apply it on the DIV element? >> >> I'm confused. If you are opposed to this pace, then what div element? > > That was a question in reply to what James wrote. It appeared to be an > error. > >> It may also be helpful to look at a specific feed, for example this one: >> >> http://www.imc.org/atom-syntax/mail-archive/msg12902.html >> >> Experiment with alternate serializations if you like. >> >> The important question is whether the
element is part of the >> format or part of the content? Should aggregators copy it? When an >> Atom entry is POSTed to a blog, is the div part of the content? > > If the page is adopted, which I hope not, it MUST NOT be part of the > content. If the page is not adopted it MUST be part of the content. I can easily sit back and adopt a "wait and see" and "I told you so" attitude, but by now it should be obvious that I care too much about the success of this format and protocol to do that. If this Pace is not adopted, the following predictions can be made: 1) Graham (who uses proper XML tools) will have to do more work. 2) Tim (who uses string concatenation) will have to do more work. 3) More feeds will be harder to read (that's why I asked you to experiment with alternate serializations. 3) More feeds will be invalid (content in atom namespace) 4) More feeds will be incorrect (in the sense that Tim's feed does accurately reflect the content of his entries). 5) For some combinations of clients and servers, entries produced via an HTTP POST will end up with multiple
s. Meanwhile, now that the location where the namespace can be declared details have been removed from this pace, Henri can continue to do a DOM-to-DOM copy. I stand by my original statements: There are cases where explicit is better than implicit. Given that common practice is to include this element, making it mandatory makes things clearer to both people who are producing consuming tools based on the spec, and people who are producing new feeds based on copy and paste. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 16:30:43 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22684 for ; Mon, 7 Feb 2005 16:30:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LL1WE067558; Mon, 7 Feb 2005 13:21:01 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LL1E7067557; Mon, 7 Feb 2005 13:21:01 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc13.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LL11e067544 for ; Mon, 7 Feb 2005 13:21:01 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc13) with SMTP id <20050207212056015009mikhe>; Mon, 7 Feb 2005 21:20:56 +0000 Date: Mon, 7 Feb 2005 14:20:54 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceProfile From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1. I may have missed something, but I didn't see it specified whether one document could list more than one profile or not. I think it should not be allowed. With multiple profiles mixed, it would be more difficult to figure out exactly what to expect, and I don't expect it to be necessary--if you want to specify a feed that's a hybrid of two profiles, create another profile that describes exactly what you're after. Profiles could take care of the job of specifying how to create what I recently referred to as Collection Documents and Archive Documents (identical except that multiple versions of a particular entry would be allowed in Archive Documents). I would be fine with dropping PaceArchiveDocument, and allowing and in head (PaceCommentFeeds--let's keep link/@rel="comments" though) if this is accepted. Question: If head-in-entry were removed from the spec, could a profile indicate that could contain a that specified the feed data relevant to the entry? I'd be in favor of handling aggregation that way, and would support PaceAggregationInSeparateSpec, and would be happy to drop PaceAggregationDocument and PaceAggregationDocument2 if that were the case. From owner-atom-syntax@mail.imc.org Mon Feb 7 16:35:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23573 for ; Mon, 7 Feb 2005 16:35:22 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LRoou068490; Mon, 7 Feb 2005 13:27:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LRos2068489; Mon, 7 Feb 2005 13:27:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LRn8n068482 for ; Mon, 7 Feb 2005 13:27:50 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17LRjkd024218; Mon, 7 Feb 2005 16:27:46 -0500 (EST) Message-ID: <4207DD30.5000704@intertwingly.net> Date: Mon, 07 Feb 2005 16:27:12 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Powell CC: Atom WG Subject: Re: PaceEntryOrder References: <4207AE39.7010507@franklinmint.fm> <4207C023.3050504@intertwingly.net> <1759188609.20050207211428@djpowell.net> In-Reply-To: <1759188609.20050207211428@djpowell.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Powell wrote: > Monday, February 7, 2005, 7:23:15 PM, you wrote: > >>I'm +1 on the Pace as written. I'd be equally +1 on a modifed Pace >>where "SHOULD NOT" was used in place of "MUST NOT". > > Sam, have you misread the Pace? The only occurrence of "MUST NOT" is > in the Rationale, where it has been copied from Atom 0.3 as an > example. > > The proposal is to add the following paragraph: > > This specification assigns no significance to the order of > atom:entry elements within the feed. Processors MAY present entries > in a different order to which they are appear in an Atom Feed > Document. > > Also, Walter's comment seems to suggest the same confusion: > >>-1. I don't see the benefit. Clients MAY re-order them, but that >>doesn't mean they MUST ignore the order. The publisher may prefer an >>order which cannot be expressed in the attributes. The Macintouch >>and BBC New feeds cited before are good examples. > > I'll try to be a bit more conservative with the PRE tags in future :) Yes, I misread it. To be clear: 1) I am +1 to the original wording that somehow got "lost". 2) I am +1 to the proposed rewording. Ultimately, the sentiment that I want conveyed is that publishers are not safe to assume that clients will read anything into the order. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 16:36:14 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23765 for ; Mon, 7 Feb 2005 16:36:14 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LOvwr068090; Mon, 7 Feb 2005 13:24:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LOvU2068089; Mon, 7 Feb 2005 13:24:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LOvj0068072 for ; Mon, 7 Feb 2005 13:24:57 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207212451014003b3u8e>; Mon, 7 Feb 2005 21:24:51 +0000 Date: Mon, 7 Feb 2005 14:24:49 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceAggregationInSeparateSpec From: Antone Roundy To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit +1 if: 1) it means that head-in-entry is removed. AND 2) profiles or some extension mechanism would enable people to do head-in-entry for those who want to use that method, but which I DON'T mean this: ... ... but this: <updated /> ... </ext:head> ... </entry> From owner-atom-syntax@mail.imc.org Mon Feb 7 16:36:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23795 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 16:36:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LPx3Q068256; Mon, 7 Feb 2005 13:25:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LPxjn068255; Mon, 7 Feb 2005 13:25:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LPwbI068231 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:25:58 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020721255301300k631pe>; Mon, 7 Feb 2005 21:25:53 +0000 Date: Mon, 7 Feb 2005 14:25:47 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceHeadless From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <D53E2E88-794E-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit -1, but if we do adopt it, let's use some name other than "feeder". From owner-atom-syntax@mail.imc.org Mon Feb 7 16:37:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24039 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 16:36:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LOaHb068046; Mon, 7 Feb 2005 13:24:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LOaV5068045; Mon, 7 Feb 2005 13:24:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LOZka068019 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:24:35 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id 745F3B6 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:24:28 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17LOSLf001545 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:24:28 -0800 (PST) Date: Mon, 07 Feb 2005 13:44:07 -0800 From: Walter Underwood <wunder@verity.com> To: Atom WG <atom-syntax@imc.org> Subject: Re: PaceEntryOrder Message-ID: <591F2178B3A6B61723CFB53E@diva.verity.com> In-Reply-To: <p0620071dbe2d7e42807e@[10.20.30.249]> References: <p06200710be2d5d27be20@[10.20.30.249]> <4207AE39.7010507@franklinmint.fm> <FD23F779EE0CC38676B2DA34@Wunders-Computer.local> <p0620071dbe2d7e42807e@[10.20.30.249]> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On Monday, February 07, 2005 12:24:15 PM -0800 Paul Hoffman <phoffman@imc.org> wrote: > At 11:07 AM -0800 2/7/05, Walter Underwood wrote: >> -1. I don't see the benefit. Clients MAY re-order them, but that >> doesn't mean they MUST ignore the order. The publisher may prefer >> an order which cannot be expressed in the attributes. The Macintouch >> and BBC New feeds cited before are good examples. > > I'm very confused. Clients that show the entries of those feeds in > the received order are perfectly acceptable according to the wording of this Pace. Correct, clients may choose any order, including the original. This is about the publisher's order preference. The Pace says that the publisher cannot indicate a preferred order in the Atom format. The order is not significant. This is clearly counter to normal use, where the order does have some meaning. The meaning varies by publisher, but it is usually significant. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Mon Feb 7 16:40:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24989 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 16:40:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LYKKc069240; Mon, 7 Feb 2005 13:34:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LYKil069239; Mon, 7 Feb 2005 13:34:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LYKCq069227 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:34:20 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050207213415014003gqlqe>; Mon, 7 Feb 2005 21:34:15 +0000 Date: Mon, 7 Feb 2005 14:34:13 -0700 Subject: Re: PaceProfileAttribute Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4207DACD.7090007@gmail.com> Message-Id: <02E88248-7950-11D9-88AE-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I'm in favor of profiles, just -1 to allowing @profile on sub-elements. So I prefer PaceProfile to PaceProfileAttribute. On Monday, February 7, 2005, at 02:17 PM, James M Snell wrote: > This is entirely possible also. Just to be clear tho, you're not > -1'ing the idea of profiles, just the allowing of the @profile > attribute on sub-elements (e.g. entries contained in feeds) correct? > This is an important distinction because I'm definitely not married to > the syntax as presented but would definitely like to see us adopt the > profile mechanism in general. > > - James M Snell > > Antone Roundy wrote: >> -1: One profile (or maybe set of profiles) per document is better in >> my opinion. If an aggregator aggregates entries with different >> profiles, it can either fix them up as needed to conform to a common >> profile, or if multiple profiles can be specified at the top level, >> declare the profiles for all of the entries in the document there. > From owner-atom-syntax@mail.imc.org Mon Feb 7 16:53:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28422 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 16:53:49 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LjUkb070675; Mon, 7 Feb 2005 13:45:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LjUNX070674; Mon, 7 Feb 2005 13:45:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LjTcx070663 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:45:30 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1661830wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 13:45:24 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=SmBXy0zZdWlsT9oDItMMEWlORpcJnF3WP976skBis8HqwQM0428c7Z/40KQVD8Tny6CTZG1I8xV3SSnKsdSs6Vp7FKAE2YHXRca0nddJf1oSnXBmmNhQBlVPvmIvjtdTWf6j08qh0YkFIQGD0sRsxk+EtwsdDSlXVTbTyKcFOsQ= Received: by 10.54.24.57 with SMTP id 57mr172698wrx; Mon, 07 Feb 2005 13:45:23 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 45sm163043wri.2005.02.07.13.45.23; Mon, 07 Feb 2005 13:45:23 -0800 (PST) Message-ID: <4207E16D.9060605@gmail.com> Date: Mon, 07 Feb 2005 13:45:17 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy <antone@geckotribe.com>, atom-syntax@imc.org Subject: Re: PaceProfile References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> In-Reply-To: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit The specification of multiple profiles is one of the differences between PaceProfile and PaceProfileAttribute. Mark's original proposal does not allow for multiple profiles, mine does. Mark's Proposal: * @profile or modified @version on the document level * one profile per document * profile applies to the entire document * a profile describes what metadata elements are required and cardinality thereof My Proposal: * @profile on the <atom:feed /> and <atom:entry /> levels (independent of document arrangement) * multiple profiles per <atom:feed /> <atom:entry /> * profile applies just to the <atom:feed /> or <atom:entry /> element upon which it appears. it does not apply recursively down the structure. * a profile describes what metadata elements are required and cardinality thereof * profile is strictly informational and does not impose any operational requirements on the part of consumers/producers Mine is admitedly more complex, but it also, in my opinion, provides greater flexibility. Whether that greater flexibility is required is a separate question that is open for debate. WRT multiple profiles, since all a profile is is a statement of which elements are required and the cardinality thereof, the union of the profile requirements is what is expected in the document. For instance, if profileA requires <foo /> and profileB requires <bar />, processors should expect <foo /> and <bar />. The only contention will be if profileA and profileB specify requirements for a different cardinality of some common element. e.g. profileB requires no more than 1 <foo /> and profileA requires no fewer than 2 <foo />. If the element contains 2 <foo />, then the processor determines that the element is conformant with profileA, but not profileB. It is up to the processor to figure out what to do in such cases. Alternatively, a rule can be specified that the profile with the highest cardinality for element <foo /> takes precedence. For interoperability sake, the creation of profiles should have a somewhat high bar. creating "another profile that describes exactly what you're after" should not be something done willy-nilly if you expect people to have a clue what they're producing/processing. Restricting profiles as we've done, composing multiple well-defined profiles on the fly will be more reliably interoperable than creating a brand new profile to fit some specific situation. > Question: If head-in-entry were removed from the spec, could a profile > indicate that <entry> could contain a <head> that specified the feed > data relevant to the entry? I'd be in favor of handling aggregation > that way, and would support PaceAggregationInSeparateSpec, and would be > happy to drop PaceAggregationDocument and PaceAggregationDocument2 if > that were the case. Yes, with either option (PaceProfile or PaceProfileAttribute). - James M Snell Antone Roundy wrote: > > +1. > > I may have missed something, but I didn't see it specified whether one > document could list more than one profile or not. I think it should not > be allowed. With multiple profiles mixed, it would be more difficult to > figure out exactly what to expect, and I don't expect it to be > necessary--if you want to specify a feed that's a hybrid of two > profiles, create another profile that describes exactly what you're after. > > Profiles could take care of the job of specifying how to create what I > recently referred to as Collection Documents and Archive Documents > (identical except that multiple versions of a particular entry would be > allowed in Archive Documents). I would be fine with dropping > PaceArchiveDocument, and allowing <content> and <summary> in head > (PaceCommentFeeds--let's keep link/@rel="comments" though) if this is > accepted. > > Question: If head-in-entry were removed from the spec, could a profile > indicate that <entry> could contain a <head> that specified the feed > data relevant to the entry? I'd be in favor of handling aggregation > that way, and would support PaceAggregationInSeparateSpec, and would be > happy to drop PaceAggregationDocument and PaceAggregationDocument2 if > that were the case. > > From owner-atom-syntax@mail.imc.org Mon Feb 7 16:57:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29772 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 16:57:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LneSl071302; Mon, 7 Feb 2005 13:49:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Lned0071301; Mon, 7 Feb 2005 13:49:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Lndod071294 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:49:40 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyGlD-0007JW-Rj; Mon, 07 Feb 2005 21:49:35 +0000 Message-ID: <4207E271.9090608@franklinmint.fm> Date: Mon, 07 Feb 2005 16:49:37 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy <antone@geckotribe.com> CC: atom-syntax@imc.org Subject: Re: PaceProfile References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> In-Reply-To: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit -1, I guess. This Pace proposes an organization of the spec which assumes we accept PaceProfileAttribute and/or keep the version attribute. I think the layout is reasonable for that scenario, but it overlaps with PaceExtensionConstruct and some others. I don't really see much reason to do a Pace for this. Perhaps it's meant to counter PaceOrderSpecAlphabetically. I'm not really opposed to either Pace, but these are editorial issues, which the WG can address after the format is locked down. Right now, I feel they are just confusing matters. I think we should close them and deal with this problem around Feb 21ish[0]. Robert Sayre [0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html From owner-atom-syntax@mail.imc.org Mon Feb 7 17:00:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00647 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:00:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LsRl0071881; Mon, 7 Feb 2005 13:54:27 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LsRgP071880; Mon, 7 Feb 2005 13:54:27 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LsQbX071873 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:54:26 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyGpo-0007Ms-Ka; Mon, 07 Feb 2005 21:54:20 +0000 Message-ID: <4207E38D.607@franklinmint.fm> Date: Mon, 07 Feb 2005 16:54:21 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Anne van Kesteren <fora@annevankesteren.nl>, atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <D5020DB9-7941-11D9-88AE-003065EA6144@geckotribe.com> <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> In-Reply-To: <4207DBF0.60308@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > I can easily sit back and adopt a "wait and see" and "I told you so" > attitude, but by now it should be obvious that I care too much about the > success of this format and protocol to do that. > After watching this WG fail to communicate clearly on this matter, and make a variety of arcane XML serialization mistakes in the course of discussion, it's clear to me that Sam is right. +1 to PaceXhtmlNamespaceDiv Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 17:02:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01392 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:02:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LvUZ2072182; Mon, 7 Feb 2005 13:57:30 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17LvUH3072181; Mon, 7 Feb 2005 13:57:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17LvT6R072165 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:57:29 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id EE2FF89 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:57:24 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j17LvNLf001703 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 13:57:24 -0800 (PST) Date: Mon, 07 Feb 2005 13:56:17 -0800 From: Walter Underwood <wunder@verity.com> To: Atom WG <atom-syntax@imc.org> Subject: Re: PaceEntryOrder Message-ID: <9241BCA325F93F5692EE54D1@Wunders-Computer.local> In-Reply-To: <4207DD30.5000704@intertwingly.net> References: <p06200710be2d5d27be20@[10.20.30.249]> <4207AE39.7010507@franklinmint.fm> <FD23F779EE0CC38676B2DA34@Wunders-Computer.local> <4207C023.3050504@intertwingly.net> <1759188609.20050207211428@djpowell.net> <4207DD30.5000704@intertwingly.net> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On February 7, 2005 4:27:12 PM -0500 Sam Ruby <rubys@intertwingly.net> wrote: > > Ultimately, the sentiment that I want conveyed is that publishers are not > safe to assume that clients will read anything into the order. And I think that the order should mean "the publisher put them in this order." The Pace forbids that interpretation. Clients can reorder things, show only a few, whatever. I'm not restricting client behavior. Do other specs in the RSS family say anything about order? If order is significant in those, then making it not significant in Atom will hurt interoperability. Hmm, I can't finding any ordering restrictions in a quick read of RSS 0.91 and 2.0, but RSS 1.0 does specify ordering. >From RSS 1.0: 5.3.5 <items> An RDF Seq (sequence) is used to contain all the items rather than an RDF Bag to denote item order for rendering and reconstruction. <http://web.resource.org/rss/1.0/spec#s5.3.5> wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 17:20:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05586 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:20:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17M89Is074029; Mon, 7 Feb 2005 14:08:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17M89OM074028; Mon, 7 Feb 2005 14:08:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.200]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17M88ph074008 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 14:08:08 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1605468wra for <atom-syntax@imc.org>; Mon, 07 Feb 2005 14:08:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=IpOZ+neS6pnm6F4/efQjfQxVcoEOlJW7T8hwR5bn112FKiWvwhuLSlHMDVv6PEQ/s/vIJFhtLrdRrlXIxvjYahY9HxI31akOWHeP6ojLtew3drmheNoZ1IFuu8PTM35kloeJecS2dkDARu8aXwAhh8ELrLZActgpPdndrqrYnfs= Received: by 10.54.46.67 with SMTP id t67mr82891wrt; Mon, 07 Feb 2005 14:08:02 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id d6sm104687wra.2005.02.07.14.08.02; Mon, 07 Feb 2005 14:08:02 -0800 (PST) Message-ID: <4207E6BC.5030408@gmail.com> Date: Mon, 07 Feb 2005 14:07:56 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm>, atom-syntax@imc.org Subject: Re: PaceProfile References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> <4207E271.9090608@franklinmint.fm> In-Reply-To: <4207E271.9090608@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Actually, PaceProfile was proposed prior to PaceProfileAttribute and is an independent proposal. I offered PaceProfileAttribute as a separate proposal because 1) PaceProfile didn't really specify any specifics for the the @profile attribute beyond suggesting that it be created or that @version be modified and 2) I did not think that a complete restructuring of the document was really necessary. I tried to be more specific in PaceProfileAttribute. I am quite certain that Mark has his own ideas with regards to PaceProfile and that he would not agree that PaceProfile depends on PaceProfileAttribute in any way. Likewise, PaceProfileAttribute has no dependencies on PaceProfile. - James M Snell Robert Sayre wrote: > > -1, I guess. This Pace proposes an organization of the spec which > assumes we accept PaceProfileAttribute and/or keep the version > attribute. I think the layout is reasonable for that scenario, but it > overlaps with PaceExtensionConstruct and some others. I don't really see > much reason to do a Pace for this. Perhaps it's meant to counter > PaceOrderSpecAlphabetically. > > I'm not really opposed to either Pace, but these are editorial issues, > which the WG can address after the format is locked down. Right now, I > feel they are just confusing matters. I think we should close them and > deal with this problem around Feb 21ish[0]. > > Robert Sayre > > [0] http://www.imc.org/atom-syntax/mail-archive/msg12981.html > > From owner-atom-syntax@mail.imc.org Mon Feb 7 17:30:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06921 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:30:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MMjY3075608; Mon, 7 Feb 2005 14:22:45 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17MMjQx075607; Mon, 7 Feb 2005 14:22:45 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MMg1J075600 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 14:22:44 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyHHC-0007bx-3S; Mon, 07 Feb 2005 22:22:38 +0000 Message-ID: <4207EA2F.6060603@franklinmint.fm> Date: Mon, 07 Feb 2005 17:22:39 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: atom-syntax@imc.org Subject: Re: PaceProfile References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> <4207E271.9090608@franklinmint.fm> <4207E6BC.5030408@gmail.com> In-Reply-To: <4207E6BC.5030408@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit James M Snell wrote: > I am quite certain that Mark has his > own ideas with regards to PaceProfile and that he would not agree that > PaceProfile depends on PaceProfileAttribute in any way. Likewise, > PaceProfileAttribute has no dependencies on PaceProfile. > Oh! This isn't editorial at all, then. I guess I'd have to see some more spec text, then. I'm not sure what Mark is proposing. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 17:48:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08481 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:48:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Mfebq077349; Mon, 7 Feb 2005 14:41:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Mfeea077348; Mon, 7 Feb 2005 14:41:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MfdOa077341 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 14:41:40 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17MfaCi007170 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:41:37 -0500 (EST) Message-ID: <4207EE7F.2080208@intertwingly.net> Date: Mon, 07 Feb 2005 17:41:03 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceProfile References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> <4207E271.9090608@franklinmint.fm> <4207E6BC.5030408@gmail.com> <4207EA2F.6060603@franklinmint.fm> In-Reply-To: <4207EA2F.6060603@franklinmint.fm> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > James M Snell wrote: > >> I am quite certain that Mark has his >> own ideas with regards to PaceProfile and that he would not agree that >> PaceProfile depends on PaceProfileAttribute in any way. Likewise, >> PaceProfileAttribute has no dependencies on PaceProfile. > > Oh! This isn't editorial at all, then. I guess I'd have to see some more > spec text, then. I'm not sure what Mark is proposing. I missed that too... otherwise I would have simply put this Pace in the Recommended for Closure list. -1 on this Pace until section 6 is flushed out. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 17:55:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09066 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:55:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MnPuU078185; Mon, 7 Feb 2005 14:49:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17MnPrs078184; Mon, 7 Feb 2005 14:49:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MnOAc078178 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 14:49:24 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06200723be2da09c8db2@[10.20.30.249]> In-Reply-To: <4207EA2F.6060603@franklinmint.fm> References: <268D856C-794E-11D9-88AE-003065EA6144@geckotribe.com> <4207E271.9090608@franklinmint.fm> <4207E6BC.5030408@gmail.com> <4207EA2F.6060603@franklinmint.fm> Date: Mon, 7 Feb 2005 14:49:22 -0800 To: Atom WG <atom-syntax@imc.org> From: Paul Hoffman <phoffman@imc.org> Subject: Re: PaceProfile Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> -1 because it is incomplete (no text for the new profiles in Section 6). The specification of those profiles could have a major technical effect on the rest of the document. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 17:55:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA09154 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 17:55:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17MlrCe078009; Mon, 7 Feb 2005 14:47:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Mlr41078008; Mon, 7 Feb 2005 14:47:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Mlphj077993 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 14:47:52 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06200722be2da046795d@[10.20.30.249]> Date: Mon, 7 Feb 2005 14:47:43 -0800 To: Atom WG <atom-syntax@imc.org> From: Paul Hoffman <phoffman@imc.org> Subject: PaceProfileAttribute Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> -1 because it doesn't feel like it belongs in the core. That is, when more developers have real profiles that they want to differentiate from the atom core, adding a @profile attribute seems like a good extension. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 18:07:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12449 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:07:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17N0nbk079241; Mon, 7 Feb 2005 15:00:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17N0nu2079240; Mon, 7 Feb 2005 15:00:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from picanmix.dev.day.com (bsl-rtr.day.com [212.249.34.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17N0mL8079212 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:00:48 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j17N0YK03519 for <atom-syntax@imc.org>; Tue, 8 Feb 2005 00:00:34 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005020800003182:31820 ; Tue, 8 Feb 2005 00:00:31 +0100 Mime-Version: 1.0 (Apple Message framework v619.2) In-Reply-To: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> References: <9C395894-629F-11D9-B5EE-000D93324AD6@gbiv.com> Message-Id: <c7909f9b10c163d9b6e9c8aa4c052be2@gbiv.com> From: "Roy T. Fielding" <fielding@gbiv.com> Subject: withdraw PaceFeedRecursive Date: Mon, 7 Feb 2005 15:00:31 -0800 To: Atom WG <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619.2) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 12:00:32 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 12:00:34 AM, Serialize complete at 02/08/2005 12:00:34 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Please withdraw PaceFeedRecursive because forcing everything to be an entry is sufficient justification to forbid inclusion by anything other than reference. The other (still needed) bits are in PaceHeadless. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/> From owner-atom-syntax@mail.imc.org Mon Feb 7 18:14:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13736 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:14:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17N6aFB079841; Mon, 7 Feb 2005 15:06:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17N6afw079840; Mon, 7 Feb 2005 15:06:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17N6arn079824 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:06:36 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc11) with SMTP id <2005020723063001300kevg6e>; Mon, 7 Feb 2005 23:06:30 +0000 Date: Mon, 7 Feb 2005 16:06:29 -0700 Subject: Re: PaceProfile Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit In-Reply-To: <4207EE7F.2080208@intertwingly.net> Message-Id: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Monday, February 7, 2005, at 03:41 PM, Sam Ruby wrote: > Robert Sayre wrote: >> James M Snell wrote: >>> I am quite certain that Mark has his >>> own ideas with regards to PaceProfile and that he would not agree >>> that PaceProfile depends on PaceProfileAttribute in any way. >>> Likewise, PaceProfileAttribute has no dependencies on PaceProfile. >> Oh! This isn't editorial at all, then. I guess I'd have to see some >> more spec text, then. I'm not sure what Mark is proposing. > > I missed that too... otherwise I would have simply put this Pace in > the Recommended for Closure list. > > -1 on this Pace until section 6 is flushed out. > Please finish it! If it turns out close to the way I understand it from what's already there and the discussion thus far, it will keep my support. From owner-atom-syntax@mail.imc.org Mon Feb 7 18:15:26 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14028 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:15:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17N7BA4079898; Mon, 7 Feb 2005 15:07:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17N7BTw079897; Mon, 7 Feb 2005 15:07:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17N79S4079869 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:07:10 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 07 Feb 2005 23:06:57 -0000 Received: from pD9E5162A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.22.42) by mail.gmx.net (mp008) with SMTP; 08 Feb 2005 00:06:57 +0100 X-Authenticated: #1915285 Message-ID: <4207F48B.9000505@gmx.de> Date: Tue, 08 Feb 2005 00:06:51 +0100 From: Julian Reschke <julian.reschke@gmx.de> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anne van Kesteren <fora@annevankesteren.nl> CC: Henri Sivonen <hsivonen@iki.fi>, Paul Hoffman <phoffman@imc.org>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <p0620070cbe2d5af93b61@[10.20.30.249]> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> In-Reply-To: <4207CAAB.30906@annevankesteren.nl> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Anne van Kesteren wrote: > > Henri Sivonen wrote: > >> -1 on PaceXhtmlNamespaceDiv > > > -1 from me as well. It is hack which might be useful for publishing > systems (and perhaps aggregators) who do not use the right tools to > generate a valid Atom file anyway. Same here: -1 -- <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Mon Feb 7 18:19:22 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14744 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:19:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NBo4g080509; Mon, 7 Feb 2005 15:11:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NBo4G080508; Mon, 7 Feb 2005 15:11:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NBooZ080500 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:11:50 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyI2i-0008DT-V6 for atom-syntax@imc.org; Mon, 07 Feb 2005 23:11:45 +0000 Message-ID: <4207F5B2.4080208@franklinmint.fm> Date: Mon, 07 Feb 2005 18:11:46 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom-Syntax <atom-syntax@imc.org> Subject: Service Constructs? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Looks like we forgot to write a formal Pace for removing the protocol elements. Proposed by Julian: http://www.imc.org/atom-syntax/mail-archive/msg12887.html +1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and Underwood. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 18:31:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15743 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:31:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NJpgE081350; Mon, 7 Feb 2005 15:19:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NJpP7081349; Mon, 7 Feb 2005 15:19:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NJotu081314 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:19:50 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1624189wra for <atom-syntax@imc.org>; Mon, 07 Feb 2005 15:19:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hdhrFZl3aMGgGg4PN0U7LBgn7yogaFhnNVO6hMCkNo7YJuBnyE0ySWdRqqrZbox7BFMjtHAAPCbNlveB7ZQePyjs0IsVyUb21rxozGZWK19OOUMVhctud9ZKyEnutDkVAPSJ9Pg/LJkg7TXlCc7490AxQRQSJDtE/pJCVWcXOOc= Received: by 10.54.57.80 with SMTP id f80mr89626wra; Mon, 07 Feb 2005 15:19:44 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 43sm358376wri.2005.02.07.15.19.44; Mon, 07 Feb 2005 15:19:44 -0800 (PST) Message-ID: <4207F78A.6020306@gmail.com> Date: Mon, 07 Feb 2005 15:19:38 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman <phoffman@imc.org>, atom-syntax@imc.org Subject: Re: PaceProfileAttribute References: <p06200722be2da046795d@[10.20.30.249]> In-Reply-To: <p06200722be2da046795d@[10.20.30.249]> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > > -1 because it doesn't feel like it belongs in the core. That is, when > more developers have real profiles that they want to differentiate from > the atom core, adding a @profile attribute seems like a good extension. Hmm. the challenge with this assertion is that the atom spec as it stands today, does not give someone the option of being able to override the metadata containment requirements as specified by the core. Nor does it give any indication how such redefinition should occur. This spec does not introduce any other profiles, it just provides the framework under which profiles can be created and cooks that into the core so that doing so can be done in a consistent, reliable manner. Further, one would need to consider how a @profile differs from a @version and the namespace attribute, etc. This proposal replaces @version completely with the @profile mechanism. The namespace is used to identify the semantics of the individual elements themselves while the profile is used to identify the containment requirements. As the spec stands currently, the relationship between atom namespace+@version+containment requirements+element semantics is muddled up. Is it possible for someone to modify containment requirements for a specific use case while adhering to the same atom namespace? The @version attribute is defined such that it relates to Atom spec version. Does @version reflect element semantics or containment requirements or both? This proposal says, namespace==element semantics, @profile=containment requirements and provides a clear, consistent approach to handling different/multiple @profiles. That is a far cry from the minimal and far-from-helpful "atom:feed elements MUST have a "version" attribute whose content indicates the version of the Atom specification that the feed conforms to. The content of this attribute is unstructured text." Also, as others have pointed out, the profile attribute mechanism could be used to handle cases such as defining the requirements for an archive as opposed to creating a new top level archive element. Bottom line: while @profile COULD be added as an extension, I think it is much more valuable in the core as a replacement to @version. - James M Snell From owner-atom-syntax@mail.imc.org Mon Feb 7 18:31:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15753 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:31:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NLaGI081594; Mon, 7 Feb 2005 15:21:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NLaUw081593; Mon, 7 Feb 2005 15:21:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NLZ5K081577 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:21:36 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 63so1628wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 15:21:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hO+G474h3xmRi0RRqUdS5ZOQCOtbFv/LzPkoQN89RHbT+vBG4nD5F0ijWxWd7BQS0xTqKrIRdrElwV9LdkuF534BBgFwY6hAONIulVKbCLoGwIQ1+ToogaiKLU2quADmd5hXPUnbr1fnIHzipgTryP+2jyMdmyY4ldrMbxku1OM= Received: by 10.54.20.13 with SMTP id 13mr8106wrt; Mon, 07 Feb 2005 15:21:30 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 67sm3810wra.2005.02.07.15.21.29; Mon, 07 Feb 2005 15:21:30 -0800 (PST) Message-ID: <4207F7F3.5060009@gmail.com> Date: Mon, 07 Feb 2005 15:21:23 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm>, atom-syntax@imc.org Subject: Re: Service Constructs? References: <4207F5B2.4080208@franklinmint.fm> In-Reply-To: <4207F5B2.4080208@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1 on this also. They shouldn't be in the core - James M Snell Robert Sayre wrote: > > Looks like we forgot to write a formal Pace for removing the protocol > elements. > > Proposed by Julian: > http://www.imc.org/atom-syntax/mail-archive/msg12887.html > > +1s from Sayre, Bray, Gregorio. Less positive comments from Hoffman and > Underwood. > > Robert Sayre > > From owner-atom-syntax@mail.imc.org Mon Feb 7 18:31:46 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15782 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:31:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NMIcX081680; Mon, 7 Feb 2005 15:22:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NMIrM081679; Mon, 7 Feb 2005 15:22:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from picanmix.dev.day.com (bsl-rtr.day.com [212.249.34.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NMGVI081670 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:22:17 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j17NMFK04426; Tue, 8 Feb 2005 00:22:15 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005020800221228:31847 ; Tue, 8 Feb 2005 00:22:12 +0100 In-Reply-To: <b8f5cb567ff3950c5c98c67d846f6c11@mnot.net> References: <158887418.20050201230634@djpowell.net> <1311114903.20050203001838@djpowell.net> <8d352b08be6964ebc999a535e9c13f76@mnot.net> <3f1451f505020506265ce98c47@mail.gmail.com> <bdaa7b8edb8d3aa0a9aafe08d28852ef@mnot.net> <b70fcba3780003d608642798c438ee1e@gbiv.com> <b8f5cb567ff3950c5c98c67d846f6c11@mnot.net> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <51b0e84789a45f47d5dbb17e98f7640c@gbiv.com> Cc: Atom Syntax <atom-syntax@imc.org> From: "Roy T. Fielding" <fielding@gbiv.com> Subject: Re: mustUnderstand, mustIgnore [was: Posted PaceEntryOrder] Date: Mon, 7 Feb 2005 15:22:12 -0800 To: Mark Nottingham <mnot@mnot.net> X-Mailer: Apple Mail (2.619.2) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 12:22:12 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 12:22:15 AM, Serialize complete at 02/08/2005 12:22:15 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Feb 6, 2005, at 6:50 PM, Mark Nottingham wrote: > On Feb 5, 2005, at 6:01 PM, Roy T.Fielding wrote: >> The problem with that statement (about HTTP) is that absence of a >> must-understand in HTTP is not one of its big problems. Yes, I know >> lots of people have talked about it as a limiting factor in the >> syntax of HTTP, but to call it an actual problem would say that it >> prevented some good from being accomplished. > > It arguably tipped some people towards SOAP when HTTP would have been > adequate. That's not a prevention of good, but we've already seen > enough fragmentation in the syndication world. Well, arguably, those same applications should have been tipped into the waste basket in the first place. But I don't think you followed my main point: must understand is a mechanism to enable fragmentation -- its very presence leads away from standardization. Lack of mU is one of the reasons that HTTP is not fragmented (along with me being a stubborn pain in the ass). Hence, it is only a problem for some applications that were of questionable character, and it remains unclear whether HTTP would have benefitted by having a mU feature or if its presence would have led to a complete meltdown. >> Things that a syndication format might want to make mandatory are >> copyright controls and micropayments, but both have been shown in >> practice to require either a willingness on the part of the recipient >> to accept that specific restriction (i.e., human intervention and >> understanding) or forceful requirement by the sender (i.e., >> encryption). In both cases, agreements have to be established with >> the user in advance, before they even receive the content, and thus >> do not need a "must understand" feature. > > I don't think mU is intended for such things; rather, the case for mU > could be characterised as extensions that change the operation of the > protocol in a manner that renders it useless or misleading to try to > use the feed if you don't know what to do with the extension. It's > advisory. Right, but look at my examples and try to think of any others that would require changes in operation on the behalf of recipients. There may be others, but I am not aware of any more. >> In fact, "must understand" has no value in a network-based >> application except as positive guidance for intermediaries, which is >> something that can still be accomplished under mustIgnore with a bit >> of old-fashioned advocacy. > > So, if I can restate your position, you're saying that you don't > dispute that understanding some extensions may be required, but that > it isn't necessary to make that visible to the processor, because > it'll be co-ordinated beforehand (e.g., through market forces, > out-of-band-communication), correct? No, my position is that it isn't necessary to include mU in the format. Within the control data of an interaction protocol, sure, but not within the payload of completed actions, wherein any such requirements are far too late and susceptible to abuse. Just to be clear that I am not completely against mU in all protocols, that feature does exist in waka because it is useful when talking through intermediaries. ....Roy From owner-atom-syntax@mail.imc.org Mon Feb 7 18:32:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15838 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:32:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NJXQV081298; Mon, 7 Feb 2005 15:19:33 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NJX5G081297; Mon, 7 Feb 2005 15:19:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NJWid081278 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:19:32 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j17NJ3KT019523; Mon, 7 Feb 2005 23:19:09 GMT In-Reply-To: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org From: Graham <dtcd@mac.com> Subject: Re: PaceProfile Date: Mon, 7 Feb 2005 23:19:04 +0000 To: Antone Roundy <antone@geckotribe.com> X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Profiles seem to be a way for people who disagree with decisions made by this working group to invent their own Atom format and claim it is valid Atom. No thank you. -1 Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 18:34:53 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16006 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:34:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NRD9x082279; Mon, 7 Feb 2005 15:27:13 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NRDLn082278; Mon, 7 Feb 2005 15:27:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17NRCXJ082259 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:27:12 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 15050 messnum 3867018 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 23:27:06 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 15050) with SMTP; 7 Feb 2005 23:27:06 -0000 Message-ID: <4207F945.4010309@dehora.net> Date: Mon, 07 Feb 2005 23:27:01 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax <atom-syntax@imc.org> Subject: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready References: <B2F68BC4-7933-11D9-88AE-003065EA6144@geckotribe.com> <705fc547748c3188d295ff7b46288a9c@bblfish.net> In-Reply-To: <705fc547748c3188d295ff7b46288a9c@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Henry Story wrote: > > 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 your archive document already. Choice of model will not make an iota of difference to the core spec. I could sit here and claim that sliding window makes reordering impossible - that would be about as jaundiced and prejudicial a view as I've seen spat out about current state. What good is this doing? Can we please desist from arguing over models? Five years out we can determine if there is a sufficiently powerful model to explain syndication based on the data. Not now. cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 18:39:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16477 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:39:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NWs7e082879; Mon, 7 Feb 2005 15:32:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NWsVO082878; Mon, 7 Feb 2005 15:32:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NWrpt082856 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:32:53 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1687845wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 15:32:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=lUY3iQi2b/VgqYBNbNm9iRp0nRyTWftmx+xF2lf9mQwm4suHffXcf6NICQZ2GwD9UzaFbx7aFrnDjMny+QXseBWiv557kGrRe9eqGCNgTaBIthUDZ1xvdrzXoMR4Fajk2Nbt//0A1ZUYe3mOIP1BuCOBeivjY1At9NbbaZySYfU= Received: by 10.54.22.38 with SMTP id 38mr219678wrv; Mon, 07 Feb 2005 15:32:47 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 45sm168111wri.2005.02.07.15.32.47; Mon, 07 Feb 2005 15:32:47 -0800 (PST) Message-ID: <4207FA99.1060007@gmail.com> Date: Mon, 07 Feb 2005 15:32:41 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham <dtcd@mac.com>, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> In-Reply-To: <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit No, profiles are a way of folks to tweak the metadata containment requirements of feeds/entries for specific use cases (example: creating an archive as opposed to a syndicated feed). While I cannot speak for PaceProfile which does not call out any specific text on the matter, with PaceProfileAttribute the production of new profiles that are backwards compatible with the core profile is STRONGLY recommended but not required. PaceProfileAttribute assumes a community vetting process that optimistically assumes that a) creation of new profiles will be fairly rare and b) such profiles will only enjoy broad use if they are actually made interoperable with the core. Folks that attempt to be incompatible with the core requirements would have to convince the other Atom software providers to support their profile if they wish to achieve any level of interoperability. - James M Snell Graham wrote: > > Profiles seem to be a way for people who disagree with decisions made by > this working group to invent their own Atom format and claim it is valid > Atom. No thank you. > > -1 > > Graham > > From owner-atom-syntax@mail.imc.org Mon Feb 7 18:50:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16964 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:50:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NikCh084945; Mon, 7 Feb 2005 15:44:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Nikmp084944; Mon, 7 Feb 2005 15:44:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Nikig084938 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:44:46 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyIYa-0000Fz-QY; Mon, 07 Feb 2005 23:44:40 +0000 Message-ID: <4207FD6A.8010301@franklinmint.fm> Date: Mon, 07 Feb 2005 18:44:42 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: Graham <dtcd@mac.com>, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> In-Reply-To: <4207FA99.1060007@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > Graham wrote: > >> >> Profiles seem to be a way for people who disagree with decisions made >> by this working group to invent their own Atom format and claim it is >> valid Atom. No thank you. I'm not sure they are that antagonistic, but I agree with Paul when he says they could be added later. If profiles aren't supposed to matter to "Core Atom" processors, why not put our money where our mouth is and make profiles declare themselves in their own namespace? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 18:50:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17001 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 18:50:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NgrXY084446; Mon, 7 Feb 2005 15:42:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Ngrpi084445; Mon, 7 Feb 2005 15:42:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NgqQH084415 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:42:52 -0800 (PST) (envelope-from rogben@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1689761wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 15:42:47 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=YTaYkAHUzeBBWbC7U+0GoLxfr2dBdB6ChdaV1WFyG7Asu8Vh+dsJC0FV4Esw+CRk81hotouDPbTdu5Or59btzGn9oVlorEg1mDxJZLDtzS6lm8q1eOZfL2KqDbhBzrNqR2EgzKwSqdEEprKvf6Oxhau4kUcLa6F9eMl+5Depa6w= Received: by 10.54.41.13 with SMTP id o13mr125902wro; Mon, 07 Feb 2005 15:42:47 -0800 (PST) Received: by 10.54.18.2 with HTTP; Mon, 7 Feb 2005 15:42:47 -0800 (PST) Message-ID: <540e373205020715427f08eeb1@mail.gmail.com> Date: Mon, 7 Feb 2005 17:42:47 -0600 From: "Roger B." <rogben@gmail.com> Reply-To: "Roger B." <rogben@gmail.com> To: Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceXhtmlNamespaceDiv In-Reply-To: <4207F48B.9000505@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <412B23C4.9010602@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <p0620070cbe2d5af93b61@10.20.30.249> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit I'm +1 when wearing my aggregator hat, and indifferent from a publishing perspective. -- Roger Benningfield JournURL From owner-atom-syntax@mail.imc.org Mon Feb 7 19:00:49 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17636 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:00:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Nsc71086472; Mon, 7 Feb 2005 15:54:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NscQT086471; Mon, 7 Feb 2005 15:54:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr1.netsolmail.com (omr1.netsolmail.com [216.168.230.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NsbRd086464 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:54:38 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr1.netsolmail.com (8.12.10/8.12.10) with ESMTP id j17NsYTn004205; Mon, 7 Feb 2005 18:54:36 -0500 (EST) Received: from bobdev (static-68-236-163-34.ny325.east.verizon.net [68.236.163.34]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COL18655 (AUTH bob@wyman.us); Mon, 7 Feb 2005 18:54:34 -0500 (EST) Message-Id: <200502072354.COL18655@ms8.netsolmail.com> Reply-To: <bob@wyman.us> From: "Bob Wyman" <bob@wyman.us> To: "'Antone Roundy'" <antone@geckotribe.com>, <atom-syntax@imc.org> Subject: RE: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 18:50:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <5B80F00A-7940-11D9-88AE-003065EA6144@geckotribe.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Thread-Index: AcUNT01GIPmdAi2nRLSYqCh1VpfhSAAC4Jew Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Antone Roundy wrote: > do you have figures on how much push reduced bandwidth > use vs. RFC3229+feed? My guess would be that the difference wouldn't > be as dramatic as between feed and RFC3229+feed, but I recognize that > I may be wrong. Sorry, we don't have precise numbers. I've done the calculations in the past (it's a fairly expensive process) but then haven't kept the detail... I did the calculations for me, not for review or publication. But, you are absolutely correct in your guess that the savings of push over RFC3229+feed is less dramatic then the savings over the normal file polling. This was one of the motivations for our proposing RFC3229+feed in the first place. We wanted to make polling as efficient as possible since we get polled a lot and since we poll a lot... RFC3229+feed diminishes the bandwidth savings you get from push but doesn't eliminate those savings. That weakens the argument for push, but results in improving the overall system. > But I also don't think that we should require all Atom Documents > (other than Entry Documents) to do so. In other words, I don't think > this is an either-or question--I think both should be possible. I agree that this should not be "either-or". I would be happy if the spec said something like "multiple entries with the same atom:id MAY appear in a single feed document." I don't think it would be reasonable to insist that people insert all changes in their feeds. My goal is simply to permit this, not force it. Whether the feed contains all versions of entries should be up to the feed writer. bob wyman From owner-atom-syntax@mail.imc.org Mon Feb 7 19:01:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17694 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:01:16 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NtotO086607; Mon, 7 Feb 2005 15:55:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NtobI086606; Mon, 7 Feb 2005 15:55:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail05.svc.cra.dublin.eircom.net (mail05.svc.cra.dublin.eircom.net [159.134.118.21]) by above.proper.com (8.12.11/8.12.9) with SMTP id j17NtnEa086594 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:55:49 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 62866 messnum 373781 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 7 Feb 2005 23:55:43 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail05.svc.cra.dublin.eircom.net (qp 62866) with SMTP; 7 Feb 2005 23:55:43 -0000 Message-ID: <4207FFFA.6050503@dehora.net> Date: Mon, 07 Feb 2005 23:55:38 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Anne van Kesteren <fora@annevankesteren.nl>, atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <D5020DB9-7941-11D9-88AE-003065EA6144@geckotribe.com> <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> In-Reply-To: <4207DBF0.60308@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > If this Pace is not adopted, the following predictions can be made: > > 1) Graham (who uses proper XML tools) will have to do more work. > 2) Tim (who uses string concatenation) will have to do more work. > 3) More feeds will be harder to read (that's why I asked you to > experiment with alternate serializations. > 3) More feeds will be invalid (content in atom namespace) Perhaps I misunderstand... but this shouldn't result in invalid Atom feeds ever - content areas should be able to hold any-namespace not any-namespace-atom-namespace. Worst case is mangled content when the content is lifted out using namespace aware tools. In other words, the container markup format is just dandy, but the content they carry is potentially trashed. If we condone default namespaces this is what we can expect to happen. We discussed warning people about this broken piece of XML technology last year and it was punted to an Implementors Guide - I'm somewhat unsympathetic now if we find ourselves bitten. I'm +1 on this pace, sometimes a judicious hack is the right thing to do. I suspect it could result in <div> nesting - call it gut feeling (it's an escaping mechanism after all). cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 19:01:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17825 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:01:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NtpoM086617; Mon, 7 Feb 2005 15:55:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17Ntpo3086616; Mon, 7 Feb 2005 15:55:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Ntodo086601 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:55:50 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j17Ntgbp029036; Mon, 7 Feb 2005 18:55:43 -0500 (EST) Message-ID: <4207FFDB.1040602@intertwingly.net> Date: Mon, 07 Feb 2005 18:55:07 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke <julian.reschke@gmx.de> CC: Anne van Kesteren <fora@annevankesteren.nl>, Henri Sivonen <hsivonen@iki.fi>, Atom-Syntax <atom-syntax@imc.org> Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <p0620070cbe2d5af93b61@[10.20.30.249]> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> In-Reply-To: <4207F48B.9000505@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Anne van Kesteren wrote: > >> Henri Sivonen wrote: >> >>> -1 on PaceXhtmlNamespaceDiv >> >> -1 from me as well. It is hack which might be useful for publishing >> systems (and perhaps aggregators) who do not use the right tools to >> generate a valid Atom file anyway. > > Same here: -1 Can I get one of you three to mock up what Tim's feed should look like? http://www.imc.org/atom-syntax/mail-archive/msg12902.html - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 19:03:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18051 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:03:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NwTTa086883; Mon, 7 Feb 2005 15:58:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17NwTIL086882; Mon, 7 Feb 2005 15:58:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17NwS0W086871 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 15:58:28 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1632573wra for <atom-syntax@imc.org>; Mon, 07 Feb 2005 15:58:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=eUudrjxTJmtEnR6/v1j+3nf0PH4t9iVqEWbw/js0GuSyXXZAtCB6nc2ycDwtjO2J6gt8kVpzcsoXwiqvyK88l4P75kpH4Ibu54j3ov594NsjsfxLO3JevTywUtBlYSVwwFrY+DQjf+mXp7uJK9pxAL/z+gK6mZzf1+uGMJQPg24= Received: by 10.54.43.11 with SMTP id q11mr356150wrq; Mon, 07 Feb 2005 15:58:23 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 35sm74833wra.2005.02.07.15.58.22; Mon, 07 Feb 2005 15:58:23 -0800 (PST) Message-ID: <42080099.4000506@gmail.com> Date: Mon, 07 Feb 2005 15:58:17 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm>, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> In-Reply-To: <4207FD6A.8010301@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > I'm not sure they are that antagonistic, but I agree with Paul when he > says they could be added later. If profiles aren't supposed to matter to > "Core Atom" processors, why not put our money where our mouth is and > make profiles declare themselves in their own namespace? Suppose I want to require that a feed head MUST specify at least one category element for a specific type of use case. (just pulled the example from the air). I want folks to be able to know that I'm using alternative containment requirements. I want everything else to remain the same so that processors that aren't familiar with my modified profile can simply ignore it and process according to the core. Just so I understand exactly what you're thinking on this, how would I handle this using the extension approach? Could you provide some strawman angle brackets? - James M Snell From owner-atom-syntax@mail.imc.org Mon Feb 7 19:18:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19169 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:18:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1805qu3087592; Mon, 7 Feb 2005 16:05:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1805ptI087591; Mon, 7 Feb 2005 16:05:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-01-eri0.southeast.rr.com (ms-smtp-01-lbl.southeast.rr.com [24.25.9.100]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1805oqb087584 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:05:51 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-01-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j1805ebp008608; Mon, 7 Feb 2005 19:05:41 -0500 (EST) Message-ID: <42080233.5060201@intertwingly.net> Date: Mon, 07 Feb 2005 19:05:07 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> CC: Anne van Kesteren <fora@annevankesteren.nl>, atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <D5020DB9-7941-11D9-88AE-003065EA6144@geckotribe.com> <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> In-Reply-To: <4207FFFA.6050503@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > Sam Ruby wrote: > >> If this Pace is not adopted, the following predictions can be made: >> >> 1) Graham (who uses proper XML tools) will have to do more work. >> 2) Tim (who uses string concatenation) will have to do more work. >> 3) More feeds will be harder to read (that's why I asked you to >> experiment with alternate serializations. >> 3) More feeds will be invalid (content in atom namespace) > > Perhaps I misunderstand... but this shouldn't result in invalid Atom > feeds ever - content areas should be able to hold any-namespace not > any-namespace-atom-namespace. Worst case is mangled content when the > content is lifted out using namespace aware tools. In other words, the > container markup format is just dandy, but the content they carry is > potentially trashed. If we condone default namespaces this is what we > can expect to happen. We discussed warning people about this broken > piece of XML technology last year and it was punted to an Implementors > Guide - I'm somewhat unsympathetic now if we find ourselves bitten. Perhaps I overreached with the word "invalid", but I am of the opinion that if the type is XHTML that the content should be an xthml fragment. atom:b and atom:strong elements are examples of things which one would not expect to find in xhtml. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 19:29:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19993 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:29:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180FGJ8088770; Mon, 7 Feb 2005 16:15:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180FEde088763; Mon, 7 Feb 2005 16:15:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180Dlvl088608 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:14:54 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyJ0J-0000ln-3O; Tue, 08 Feb 2005 00:13:19 +0000 Message-ID: <42080421.2070502@franklinmint.fm> Date: Mon, 07 Feb 2005 19:13:21 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> In-Reply-To: <42080099.4000506@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit James M Snell wrote: > Robert Sayre wrote: > > I'm not sure they are that antagonistic, but I agree with Paul when he > > says they could be added later. If profiles aren't supposed to matter to > > "Core Atom" processors, why not put our money where our mouth is and > > make profiles declare themselves in their own namespace? > > Suppose I want to require that a feed head MUST specify at least one > category element for a specific type of use case. (just pulled the > example from the air). I want folks to be able to know that I'm using > alternative containment requirements. I want everything else to remain > the same so that processors that aren't familiar with my modified > profile can simply ignore it and process according to the core. Just so > I understand exactly what you're thinking on this, how would I handle > this using the extension approach? Could you provide some strawman > angle brackets? So, you're looking for a way to include a "schema" association in the feed, and you want a standard way to do it. The only processors that will do anything useful with this information are those that know about the "profile". <feed ...> <head> <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema> </head> ... </feed> You're using Atom, and processors who know about your additional requirements will know about your schema. What you're asking is for the spec to lend weight to your extensions, and I'm not very positive about that. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 19:32:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20352 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:32:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180I243089129; Mon, 7 Feb 2005 16:18:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180I2Y1089127; Mon, 7 Feb 2005 16:18:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail11.svc.cra.dublin.eircom.net ([159.134.118.27]) by above.proper.com (8.12.11/8.12.9) with SMTP id j180HRJ7088947 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:17:59 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 69982 messnum 15258241 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 00:16:42 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail11.svc.cra.dublin.eircom.net (qp 69982) with SMTP; 8 Feb 2005 00:16:42 -0000 Message-ID: <420804E5.3010808@dehora.net> Date: Tue, 08 Feb 2005 00:16:37 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby <rubys@intertwingly.net> CC: Anne van Kesteren <fora@annevankesteren.nl>, atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <D5020DB9-7941-11D9-88AE-003065EA6144@geckotribe.com> <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> In-Reply-To: <42080233.5060201@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Perhaps I overreached with the word "invalid", but I am of the opinion > that if the type is XHTML that the content should be an xthml fragment. > > atom:b and atom:strong elements are examples of things which one would > not expect to find in xhtml. Agreed (but we have already decided to allow that possibility at the container level). Still +1. cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 19:44:24 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21406 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:44:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180cKN7091323; Mon, 7 Feb 2005 16:38:20 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180cK4C091322; Mon, 7 Feb 2005 16:38:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180cJgD091314 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:38:19 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id C251FBB for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:38:14 -0800 (PST) Received: from localhost (spike.verity.com [10.69.100.102]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j180cDLf002588 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:38:14 -0800 (PST) Date: Mon, 07 Feb 2005 16:38:19 -0800 From: Walter Underwood <wunder@verity.com> To: atom-syntax@imc.org Subject: Re: PaceProfile Message-ID: <0AFEB0D35D6DDB1891179E9D@Wunders-Computer.local> In-Reply-To: <42080421.2070502@franklinmint.fm> References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> X-Mailer: Mulberry/4.0.0a4 (Mac OS X) X-Face: 7Vqnb4fOVKsO)3JuUXKxR\M]:e"u'eG`Zue*.((7i7%P%rvZgS[j~95@C-s3i (s!e;OX`'Pngn5lq*Td}#,"5!^jm(65.";[GPtD^c(/1TtMe&wYO;_}\!}fRkxs%q#Jk 5E^BlXwR+8}qOwy MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit --On February 7, 2005 7:13:21 PM -0500 Robert Sayre <mint@franklinmint.fm> wrote: > > So, you're looking for a way to include a "schema" association in the feed, > and you want a standard way to do it. The only processors that will do anything > useful with this information are those that know about the "profile". Sounds like a job for <!DOCTYPE>. Or a processing instruction, but I seem to be the only person that likes those. wunder -- Walter Underwood Principal Architect, Verity From owner-atom-syntax@mail.imc.org Mon Feb 7 19:50:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21777 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:50:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180cq1F091380; Mon, 7 Feb 2005 16:38:52 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180cqHP091379; Mon, 7 Feb 2005 16:38:52 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180cpA6091363 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:38:52 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1641341wra for <atom-syntax@imc.org>; Mon, 07 Feb 2005 16:38:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=oXcv6g+kGTsYd5+thnDuumrucYEPJZW0Njvuzpr+6lqy6gxKW8yyoIFZaysRJwj2bOhiQf1nHm16062qUTYhVfpkQMAfEiwN/cc6rdC0mk/9irITR7NArMgrISboPeh6UlAzzVTca0qUNFYI7uTEpCWbr46tMNqJJzIaezxNZ7k= Received: by 10.54.47.40 with SMTP id u40mr18823wru; Mon, 07 Feb 2005 16:38:46 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 43sm361797wri.2005.02.07.16.38.46; Mon, 07 Feb 2005 16:38:46 -0800 (PST) Message-ID: <42080A0E.8060901@gmail.com> Date: Mon, 07 Feb 2005 16:38:38 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm>, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> In-Reply-To: <42080421.2070502@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > So, you're looking for a way to include a "schema" association in the > feed, and you want a standard way to do it. The only processors that > will do anything useful with this information are those that know about > the "profile". > > <feed ...> > <head> > <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema> > </head> > ... > </feed> I don't see the value in this in that it opens up the possibility that every extension that wants to change the containment requirements could do so in some different way. It doesn't provide any guidance on how to change those requirements in a backwards compatible way, nor does it help figure out how to reconcile a situation in which multiple such extensions are applied to the same feed/entry. Further, the core spec still does not expressly allow extensions to change the containment requirements. Thus far, the only thing an extension can do is add new types of namespace qualified metadata elements. > > You're using Atom, and processors who know about your additional > requirements will know about your schema. What you're asking is for the > spec to lend weight to your extensions, and I'm not very positive about > that. > No, what I'm asking for is a single, consistent way of declaring the use of profiles and the ability to make containment requirements independent of the element definitions. The spec is not lending weight to anything but its own core profile. > Robert Sayre > From owner-atom-syntax@mail.imc.org Mon Feb 7 19:51:34 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21874 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:51:33 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180ikRp091779; Mon, 7 Feb 2005 16:44:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180ikoM091778; Mon, 7 Feb 2005 16:44:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180ijFU091772 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:44:45 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyJUZ-0001Ju-Iy; Tue, 08 Feb 2005 00:44:35 +0000 Message-ID: <42080B75.2010601@franklinmint.fm> Date: Mon, 07 Feb 2005 19:44:37 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jasnell@gmail.com CC: atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> <42080A0E.8060901@gmail.com> In-Reply-To: <42080A0E.8060901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit James M Snell wrote: > Further, the core spec > still does not expressly allow extensions to change the containment > requirements. That's right. > Thus far, the only thing an extension can do is add new > types of namespace qualified metadata elements. > Yes. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 19:53:31 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21951 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:53:30 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180mPbU092103; Mon, 7 Feb 2005 16:48:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180mPZs092102; Mon, 7 Feb 2005 16:48:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j180mOJN092084 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:48:24 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 38867 messnum 5110600 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 00:48:18 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 38867) with SMTP; 8 Feb 2005 00:48:18 -0000 Message-ID: <42080C4C.7050708@dehora.net> Date: Tue, 08 Feb 2005 00:48:12 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: jasnell@gmail.com, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> In-Reply-To: <42080421.2070502@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > So, you're looking for a way to include a "schema" association in the > feed, and you want a standard way to do it. The only processors that > will do anything useful with this information are those that know about > the "profile". > > <feed ...> > <head> > <ex:MyPetSchema>GottaHaveCategories</ex:MyPetSchema> > </head> > ... > </feed> > > You're using Atom, and processors who know about your additional > requirements will know about your schema. What you're asking is for the > spec to lend weight to your extensions, and I'm not very positive about > that. The problem is that switching on the content of an element/attribute is Atom's get out of jail card wrt extensibility. It is the default Atom extensibility model, as it's the only game we have to play that doesn't involve screwing about with the meaning of existing core data items or adding new core items. Allowing people to add elements in other namespaces under atom:feed or atom:entry and calling that extensibility is like saying a new carpet in my living room is an extension to my house - it's a crashingly weak approach. It seems to me then that if there's room for believing that there is a set of potential switches, there is room for discussing a core element/attribute to paste them into. The same argument you make against @profile can be made about @rel. Indeed you could do all this profiling stuff with a new range of values and allowing @rel on the atom:feed element, or less obvious, into the atom:feed/atom:link[@rel] part. Either of which I think I'd prefer - as we only have extensibility approach it doesn't add value of comprehension to call its slot by two different names. cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 19:55:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22029 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 19:55:11 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180o8RJ092260; Mon, 7 Feb 2005 16:50:08 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180o8I5092259; Mon, 7 Feb 2005 16:50:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from picanmix.dev.day.com (bsl-rtr.day.com [212.249.34.130]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180o6hG092241 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:50:07 -0800 (PST) (envelope-from fielding@gbiv.com) Received: from eu-mail.day.com (eu-mail.dev.day.com [10.0.0.30]) by picanmix.dev.day.com (DAY) with ESMTP id j180o1K08026; Tue, 8 Feb 2005 01:50:01 +0100 (MET) Received: from [10.2.8.58] ([10.2.8.58]) by eu-mail.day.com (Lotus Domino Release 5.0.8) with ESMTP id 2005020801495945:31919 ; Tue, 8 Feb 2005 01:49:59 +0100 In-Reply-To: <c29f9957fdab2e0f0317be370c6ab00a@bblfish.net> References: <BE2CD478.468D1%eric.scheid@ironclad.net.au> <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> <a1c85a7e0bc4b5beb9dd691362e2d8d9@gbiv.com> <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> <5ed187a16ab4416828c4ce7248357447@gbiv.com> <c29f9957fdab2e0f0317be370c6ab00a@bblfish.net> Mime-Version: 1.0 (Apple Message framework v619.2) Message-Id: <fb6a3610c51b76f19b5de84f66766691@gbiv.com> Cc: Atom Syntax <atom-syntax@imc.org> From: "Roy T. Fielding" <fielding@gbiv.com> Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Mon, 7 Feb 2005 16:49:59 -0800 To: Henry Story <henry.story@bblfish.net> X-Mailer: Apple Mail (2.619.2) X-MIMETrack: Itemize by SMTP Server on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 01:49:59 AM, Serialize by Router on eu-mail/Day(Release 5.0.8 |June 18, 2001) at 02/08/2005 01:50:01 AM, Serialize complete at 02/08/2005 01:50:01 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 5:15 AM, Henry Story wrote: >>> This is true only if you have the [Equivalence ID] interpretation >>> of the id relation. (Ie you think of id as equivId.) >> >> Yes, and to make myself perfectly clear, that means functional ID, >> as you call it, would conflict with the design of Atom and any >> reasonable design of a system wherein the things being identified >> are allowed to be updated over time. > > I wonder if you read the rest of my message... Yes, though it seems to me that you swapped the meanings of funcId and equivId somewhere between your definitions and your example, so I lost interest. > I gave an example that did not conflict with a reasonable design. On the contrary, you gave an example in which a feed contained two entries with the same id (where id here is defined as meaning the author intends this entry to supplant any prior entries with the same id). It is not reasonable to include more than one entry with the same id within the same feed representation, since all entry representations in the feed representation must validly represent the state of the feed at the time that the feed representation was generated (otherwise, it is not a feed representation at all -- it is an archive, history, ... whatever). This whole discussion presumes that it is not desirable to send all versions of all entries as part of the feed; i.e., the author specifically intends old versions of an entry to never appear in later versions of the feed. If you don't agree with that presumption, then I think you are talking about something other than what most bloggers call a feed. >> So, please, stop trying to >> make a real system fit an artificial model of graph theory that >> isn't even capable of describing the Web. Fix your model instead. > > Do you have a good paper that proves your incredibly strong statement > above? I would be happy to understand this position, as it would save > me a lot of time. Okay, but only if you promise not to extend this discussion on the atom list -- take it elsewhere if you wish to puncture my opinion -- atom should be allowed to progress in peace without invoking the defenders of RDF universality. <http://www.w3.org/TR/rdf-mt/#intro>: There are several aspects of meaning in RDF which are ignored by this semantics; in particular, it treats URI references as simple names, ignoring aspects of meaning encoded in particular URI forms [RFC 2396] and does not provide any analysis of time-varying data or of changes to URI references. It does not provide any analysis of indexical uses of URI references, for example to mean 'this document'. Some parts of the RDF and RDFS vocabularies are not assigned any formal meaning, and in some cases, notably the reification and container vocabularies, it assigns less meaning than one might expect. These cases are noted in the text and the limitations discussed in more detail. RDF is an assertional logic, in which each triple expresses a simple proposition. This imposes a fairly strict monotonic discipline on the language, so that it cannot express closed-world assumptions, local default preferences, and several other commonly used non-monotonic constructs. RDF has no capacity for temporally qualified assertions, no conceptual understanding of sink-like services, and very little habit of distinguishing between resources and representations (though it does have the capacity to deal with representations as b-nodes). Likewise, it does not differentiate between identification and use, which means it cannot be used to describe the many times in which a single URI can be used for many different things even if it only identifies (directly) one thing. The same comments apply to OWL. As previously stated, understanding the meaning of a resource is all about time. Trying to describe the Web without that dimension is a hopelessly futile effort that leads to such absurdities as declaring some URIs as being "invalid" or "inappropriate" simply because their use does not fit the artificial model of a timeless world. > But I can't just take your word for it, as there > are numerous people who don't seem to think the way you do, and in > just as senior or more senior positions than your are. My position is not based on seniority. > But perhaps > I have missed some important development recently. (I am not being > ironic here though it may sound like it. I really would like to > understand more fully your position.) No, as far as I know, there have been no recent developments that would cause the semantic web to reconsider its central assumptions. Cheers, Roy T. Fielding <http://roy.gbiv.com/> Chief Scientist, Day Software <http://www.day.com/> From owner-atom-syntax@mail.imc.org Mon Feb 7 20:02:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22926 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:02:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180sZIE092588; Mon, 7 Feb 2005 16:54:35 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180sZ4R092587; Mon, 7 Feb 2005 16:54:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180sXR5092574 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:54:34 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j180riwm006673; Tue, 8 Feb 2005 00:53:55 GMT In-Reply-To: <71234c9ab7c316582d9da9c077b76457@mac.com> References: <71234c9ab7c316582d9da9c077b76457@mac.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9956edb16de3fc4ebe7fb47df3ccc894@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: tagline -> subtitle Date: Tue, 8 Feb 2005 00:53:45 +0000 To: Graham <dtcd@mac.com> X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Did this need a Pace? It seems to have got fairly unanimous support. Graham On 2 Feb 2005, at 3:37 pm, Graham wrote: > Any chance of renaming atom:tagline to atom:subtitle? The two sample > feeds posted today have the taglines "ongoing fragmented essay by Tim > Bray" and "WebDAV related news". Aren't taglines meant to be funny or > catchy or clever? > > The relevant definitions from dictionary.com are: > tagline: An often repeated phrase associated with an individual, > organization, or commercial product; a slogan. > subtitle: A secondary, usually explanatory title, as of a literary > work. > > The second seems much broader and more useful, and there's nothing > stopping you using a slogan as subtitle. > > Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 20:07:23 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23299 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:07:23 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j180xeOG093061; Mon, 7 Feb 2005 16:59:40 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j180xeVW093060; Mon, 7 Feb 2005 16:59:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail02.svc.cra.dublin.eircom.net (mail02.svc.cra.dublin.eircom.net [159.134.118.18]) by above.proper.com (8.12.11/8.12.9) with SMTP id j180xcVn093039 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 16:59:39 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 27856 messnum 1895551 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 00:59:33 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail02.svc.cra.dublin.eircom.net (qp 27856) with SMTP; 8 Feb 2005 00:59:33 -0000 Message-ID: <42080EED.3000401@dehora.net> Date: Tue, 08 Feb 2005 00:59:25 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre <mint@franklinmint.fm> CC: jasnell@gmail.com, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> <42080A0E.8060901@gmail.com> <42080B75.2010601@franklinmint.fm> In-Reply-To: <42080B75.2010601@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Robert Sayre wrote: > > James M Snell wrote: > >> Further, the core spec still does not expressly allow extensions to >> change the containment requirements. > > That's right. With good reason - as we have no processing model in place to explain how such extensions should be evaluated we have no business allowing them. >> Thus far, the only thing an extension can do is add new types of >> namespace qualified metadata elements. > > Yes. This is not the case - we are using @rel to extend (scoped to links). cheers Bill From owner-atom-syntax@mail.imc.org Mon Feb 7 20:25:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24335 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:25:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IHIP094548; Mon, 7 Feb 2005 17:18:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IGp5094543; Mon, 7 Feb 2005 17:18:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtWn094330 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:41 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:25:44 +1100 Subject: Re: PaceEntryOrder From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5238.46C82%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceEntryOrder +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:25:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24358 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:25:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IRLn094584; Mon, 7 Feb 2005 17:18:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IPV5094583; Mon, 7 Feb 2005 17:18:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtsL094321 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:27 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:11:07 +1100 Subject: Re: PaceAggregationInSeparateSpec From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E4ECB.46C77%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceAggregationInSeparateSpec +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:30:10 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24523 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:30:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IE5a094531; Mon, 7 Feb 2005 17:18:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDaD094511; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtgU094336 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:46 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:37:37 +1100 Subject: Re: PaceJoinSectionSixAndTen From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5501.46C89%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceJoinSectionSixAndTen -1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:30:47 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24574 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:30:47 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IELD094529; Mon, 7 Feb 2005 17:18:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IBTc094513; Mon, 7 Feb 2005 17:18:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtAg094328 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:40 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:24:12 +1100 Subject: Re: PaceCollection From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E51DC.46C81%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceCollection +1 yeeouch - I had no idea just how extensive the difference in opinions as to what a <feed> represents. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:31:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24592 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:31:18 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IjXd094629; Mon, 7 Feb 2005 17:18:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181Ii9O094619; Mon, 7 Feb 2005 17:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IeqR094488 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:41 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 12:02:07 +1100 Subject: Re: PaceXhtmlNamespaceDiv From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5ABF.46CB3%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceXhtmlNamespaceDiv +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:31:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24594 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:31:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IE6B094538; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDoS094519; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Hto4094333 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:44 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:33:31 +1100 Subject: Re: PaceHeadless From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E540B.46C86%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceHeadless -1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:32:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24674 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:32:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IGbU094544; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IEQ4094528; Mon, 7 Feb 2005 17:18:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtKr094335 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:46 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:37:07 +1100 Subject: Re: PaceIconAndImage, PaceMultipleImages From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E54E3.46C88%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceIconAndImage +1 +1 to renaming atom:image to atom:logo > PaceMultipleImages -1 : multiple language variants of anything seems to be well-kyboshed anywhere in atom From owner-atom-syntax@mail.imc.org Mon Feb 7 20:32:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24699 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:32:43 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IMuD094576; Mon, 7 Feb 2005 17:18:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181ILnx094569; Mon, 7 Feb 2005 17:18:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtVk094338 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:47:47 +1100 Subject: Re: PaceLinkRelVia From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5763.46C8D%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceLinkRelVia +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:33:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24811 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:33:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IEta094530; Mon, 7 Feb 2005 17:18:15 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181ICnj094515; Mon, 7 Feb 2005 17:18:12 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtgU094340 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:54:49 +1100 Subject: Re: PaceNoFeedState From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5909.46CAE%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceNoFeedState +1 the alternative proposed so far contains instructions of traversal of feed documents ... when instead there may be other mechanisms. For example: Bob could work up a system of pushing a series of entries in response to a request for "all entries between date X and date Y". From owner-atom-syntax@mail.imc.org Mon Feb 7 20:34:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24850 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:34:01 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IESV094532; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDji094512; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Htdf094325 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:38 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:23:51 +1100 Subject: Re: PaceAggregationDocument, PaceAggregationDocument2 From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E51C7.46C81%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceAggregationDocument > PaceAggregationDocument2 -1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:34:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24901 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:34:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IEui094535; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDlg094516; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtLQ094331 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:42 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:30:31 +1100 Subject: Re: PaceFeedRecursive From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5357.46C84%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceFeedRecursive -1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:34:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24999 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:34:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IE1B094533; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDZc094514; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtHH094329 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:41 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:24:17 +1100 Subject: Re: PaceClarifyDateUpdated From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E51E1.46C81%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceClarifyDateUpdated +1. atom:updated is not atom:modified or dc:modified, and we need to guard against that if the special semantics of atom:updated are not be smothered under a flood of atom:modified pollution. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:35:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25033 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:35:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IFmf094542; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IErm094525; Mon, 7 Feb 2005 17:18:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtNZ094337 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:49 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:46:36 +1100 Subject: Re: PaceLinkEnclosure From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E571C.46C8C%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceLinkEnclosure +1 to @rel="enclosure", or @rel="attachement" as some want it From owner-atom-syntax@mail.imc.org Mon Feb 7 20:35:08 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25064 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:35:07 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Ij5u094636; Mon, 7 Feb 2005 17:18:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181Iijm094618; Mon, 7 Feb 2005 17:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IeAU094487 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:41 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 12:01:01 +1100 Subject: Re: PaceRemoveVersionAttr From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5A7D.46CB2%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceRemoveVersionAttr -0 I suspect there are good social reasons to keep @version From owner-atom-syntax@mail.imc.org Mon Feb 7 20:36:12 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25349 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:36:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IjTG094637; Mon, 7 Feb 2005 17:18:47 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181Iil6094617; Mon, 7 Feb 2005 17:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Iekt094489 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:41 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 12:08:40 +1100 Subject: Re: PaceProfile From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5C48.46CB5%eric.scheid@ironclad.net.au> In-Reply-To: <4207FD6A.8010301@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8/2/05 10:44 AM, "Robert Sayre" <mint@franklinmint.fm> wrote: > I'm not sure they are that antagonistic, but I agree with Paul when he > says they could be added later. If profiles aren't supposed to matter to > "Core Atom" processors, why not put our money where our mouth is and > make profiles declare themselves in their own namespace? would it be acceptable to use a profile to weaken cardinality rules? for example, a profile for a (S)SFF (remember them?) would allow entries as minimal as this: <entry> <id>some-id</id> <link rel="self" type="application/atom+xml" href="..." /> <updated>...</updated> </entry> how might this be represented in a namespaced extension instead? e. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:36:33 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25520 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:36:32 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IE7u094536; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDX3094518; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtJh094332 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:43 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:32:07 +1100 Subject: Re: PaceFeedState From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E53B7.46C85%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceFeedState -1 to all the traversal shenanigans being in the core +1 to link/@rel=[next|prev|self] From owner-atom-syntax@mail.imc.org Mon Feb 7 20:36:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25551 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:36:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181ILYd094571; Mon, 7 Feb 2005 17:18:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IJCW094562; Mon, 7 Feb 2005 17:18:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HwPP094363 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:55:53 +1100 Subject: Re: PaceRemoveInfoAndHost From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5949.46CAF%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceRemoveInfoAndHost +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:37:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25769 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:37:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IF0C094541; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IE4j094524; Mon, 7 Feb 2005 17:18:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtUa094323 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:30 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:21:49 +1100 Subject: Re: PaceCommentFeeds From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E514D.46C7F%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceCommentFeeds +1 to link/@rel="comment" -1 to feed/head/content +0 to feed/head/summary -- this could be informative even for non-comments feeds, a descriptive meta-data element From owner-atom-syntax@mail.imc.org Mon Feb 7 20:37:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25810 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:37:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Ijkl094630; Mon, 7 Feb 2005 17:18:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IiwC094616; Mon, 7 Feb 2005 17:18:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IeNF094486 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:41 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:51 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:57:50 +1100 Subject: Re: PaceRepeatIdInDocument From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E59BE.46CB1%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceRepeatIdInDocument +1 I'm happy with allowing multiple entries with the same ID in the one <feed> instance. Aggregators already must handle the case of seeing the same ID in some way, since that ID could quite reasonably have been in a previous edition of the <feed> resource. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:37:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25830 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:37:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IE9s094537; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDpF094521; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtNd094327 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:39 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:24:06 +1100 Subject: Re: PaceEntriesElement From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E51D6.46C81%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceEntriesElement -1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:38:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25927 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:38:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IMho094572; Mon, 7 Feb 2005 17:18:22 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IJ0i094561; Mon, 7 Feb 2005 17:18:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtoI094339 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:50 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:51:23 +1100 Subject: Re: PaceMustBeWellFormed From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E583B.46C8E%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceMustBeWellFormed -1 - needs to be re-written to avoid use of "well-formed" which has a specific meaning to some religious fanatics ;-) +1 to the general intent of this pace: explaining how publishers might get tripped up by the obscurities of technology and render their feed "broken" From owner-atom-syntax@mail.imc.org Mon Feb 7 20:39:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25983 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:39:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IMX7094574; Mon, 7 Feb 2005 17:18:23 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IK9J094563; Mon, 7 Feb 2005 17:18:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181Htvl094341 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:49 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:44:26 +1100 Subject: Re: PaceLangSpecific From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E569A.46C8B%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceLangSpecific +1, but also needed for atom:generator hmmm ... if we have xml:lang on <content>, we are going to also need @hreflang for <content src="..." />, because while some types of referenced content can have the language attached, at type="text/plain" cannot. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:39:30 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26003 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:39:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IEfW094534; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181ID5F094520; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtQ8094322 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:28 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:14:17 +1100 Subject: Re: PaceArchiveDocument From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E4F89.46C79%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceArchiveDocument -1 this looks like a backdoor to feeds in feeds. From owner-atom-syntax@mail.imc.org Mon Feb 7 20:39:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26047 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:39:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181IFdh094539; Mon, 7 Feb 2005 17:18:16 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181IDV2094522; Mon, 7 Feb 2005 17:18:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181HtsK094324 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:18:05 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 14:17:35 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 11:22:43 +1100 Subject: Re: PaceDatesXSD From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E5183.46C80%eric.scheid@ironclad.net.au> In-Reply-To: <4207A5D7.6040704@intertwingly.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit > PaceDatesXSD +1 From owner-atom-syntax@mail.imc.org Mon Feb 7 20:45:16 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26469 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 20:45:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181cAvX096099; Mon, 7 Feb 2005 17:38:10 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181cAlK096098; Mon, 7 Feb 2005 17:38:10 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.194]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181c9AL096087 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 17:38:09 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1714389wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 17:38:04 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=S4lWepLZfd01WwLs4zTFF4wWSAayH8Az0g0rFcyOCdFHtLiCD5TavF2xNfj4VLmOqLLjPU/M+VpBf1rhbU3jTsF7CxigE7jvPenvqrHJTxfV1vVV4mVHVMdy4gGT20B3TI9Uyxo7ap25NiYQaVfHVg1qCJ0S+MANpFDy9DYyTVk= Received: by 10.54.37.38 with SMTP id k38mr19418wrk; Mon, 07 Feb 2005 17:38:04 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 66sm91865wra.2005.02.07.17.38.04; Mon, 07 Feb 2005 17:38:04 -0800 (PST) Message-ID: <420817F6.9010106@gmail.com> Date: Mon, 07 Feb 2005 17:37:58 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org Subject: Re: PaceProfile References: <BE2E5C48.46CB5%eric.scheid@ironclad.net.au> In-Reply-To: <BE2E5C48.46CB5%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit With PaceProfileAttribute, weakening cardinality is possible with the strongly worded statement that new profiles SHOULD be defined so that they are backwards compatible with the core (thereby making weakened cardinality Not A Good Idea). Also, I would argue that if multiple profiles are allowed and are applied, the profile with the highest cardinality takes precendence. In other words, if someone declares that they are applying both the core profile and a profile that makes optional some element the core requires, the core takes precendence and the element is required. - James M Snell Eric Scheid wrote: > On 8/2/05 10:44 AM, "Robert Sayre" <mint@franklinmint.fm> wrote: > > >>I'm not sure they are that antagonistic, but I agree with Paul when he >>says they could be added later. If profiles aren't supposed to matter to >>"Core Atom" processors, why not put our money where our mouth is and >>make profiles declare themselves in their own namespace? > > > would it be acceptable to use a profile to weaken cardinality rules? > > for example, a profile for a (S)SFF (remember them?) would allow entries as > minimal as this: > > <entry> > <id>some-id</id> > <link rel="self" type="application/atom+xml" href="..." /> > <updated>...</updated> > </entry> > > how might this be represented in a namespaced extension instead? > > e. > > From owner-atom-syntax@mail.imc.org Mon Feb 7 21:04:15 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27745 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 21:04:15 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181vJ8i098511; Mon, 7 Feb 2005 17:57:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j181vJV7098510; Mon, 7 Feb 2005 17:57:19 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from [10.20.30.249] (dsl2-63-249-109-3.cruzio.com [63.249.109.3]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j181vHpx098503; Mon, 7 Feb 2005 17:57:18 -0800 (PST) (envelope-from phoffman@imc.org) Mime-Version: 1.0 Message-Id: <p06200729be2dcca6ac08@[10.20.30.249]> In-Reply-To: <9956edb16de3fc4ebe7fb47df3ccc894@mac.com> References: <71234c9ab7c316582d9da9c077b76457@mac.com> <9956edb16de3fc4ebe7fb47df3ccc894@mac.com> Date: Mon, 7 Feb 2005 17:57:07 -0800 To: Graham <dtcd@mac.com> From: Paul Hoffman <phoffman@imc.org> Subject: Re: tagline -> subtitle Cc: Atom Syntax <atom-syntax@imc.org> Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> At 12:53 AM +0000 2/8/05, Graham wrote: >Did this need a Pace? It seems to have got fairly unanimous support. No pace needed for editorial changes such as renaming elements or attributes if there is good agreement. The editors know full well if they make a change that angers the WG, the pitchforks will be drawn. --Paul Hoffman, Director --Internet Mail Consortium From owner-atom-syntax@mail.imc.org Mon Feb 7 21:30:25 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00042 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 21:30:25 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182IVAG000567; Mon, 7 Feb 2005 18:18:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j182IUJ8000561; Mon, 7 Feb 2005 18:18:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182HMkI000436 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 18:18:26 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc13) with SMTP id <20050208021639016004k188e>; Tue, 8 Feb 2005 02:16:39 +0000 Date: Mon, 7 Feb 2005 19:16:38 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceAggregationDocument, PaceAggregationDocument2 From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <769EE3B8-7977-11D9-BADC-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit If we adopt PaceProfile and drop head-in-entry (which could be added back in by a profile), -1 to both, otherwise +1 to PaceAggregationDocument2, or lacking that, PaceAggregationDocument. From owner-atom-syntax@mail.imc.org Mon Feb 7 21:31:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00083 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 21:31:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182GbT4000431; Mon, 7 Feb 2005 18:16:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j182GGVd000407; Mon, 7 Feb 2005 18:16:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182FeUX000346 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 18:16:05 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (sccrmhc11) with SMTP id <2005020802145001100co5lte>; Tue, 8 Feb 2005 02:14:50 +0000 Date: Mon, 7 Feb 2005 19:14:48 -0700 Mime-Version: 1.0 (Apple Message framework v553) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: PaceArchiveDocument From: Antone Roundy <antone@geckotribe.com> To: atom-syntax@imc.org Content-Transfer-Encoding: 7bit Message-Id: <34FF5578-7977-11D9-BADC-003065EA6144@geckotribe.com> X-Mailer: Apple Mail (2.553) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit If we adopt PaceProfile, then -1, otherwise +1. I'd also be fine with losing the <feed> elements and just having <archive><head /><entry />*</archive> From owner-atom-syntax@mail.imc.org Mon Feb 7 21:35:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00517 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 21:35:57 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182TaGZ001487; Mon, 7 Feb 2005 18:29:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j182Tac2001486; Mon, 7 Feb 2005 18:29:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182TY1N001416 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 18:29:35 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j182SvQU023860; Tue, 8 Feb 2005 02:29:02 GMT In-Reply-To: <BE2E5C48.46CB5%eric.scheid@ironclad.net.au> References: <BE2E5C48.46CB5%eric.scheid@ironclad.net.au> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <a76dbbac4164d317fd4bb22e092e9605@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax <atom-syntax@imc.org> From: Graham <dtcd@mac.com> Subject: Re: PaceProfile Date: Tue, 8 Feb 2005 02:28:58 +0000 To: Eric Scheid <eric.scheid@ironclad.net.au> X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8 Feb 2005, at 1:08 am, Eric Scheid wrote: > for example, a profile for a (S)SFF (remember them?) would allow > entries as > minimal as this: > > <entry> > <id>some-id</id> > <link rel="self" type="application/atom+xml" href="..." /> > <updated>...</updated> > </entry> That's not an entry so it doesn't need to be an atom:entry: <ssff:index> <atom:head> ... </atom:head> <ssff:reference> <atom:id>some-id</id> <atom:link rel="self" type="application/atom+xml" href="..." /> <atom:updated>...</updated> </ssff:reference> .... </ssff:index> (In the general case, I'd like non-compatible profiles to use different top-level/collection elements) Graham From owner-atom-syntax@mail.imc.org Mon Feb 7 21:37:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA00649 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 21:37:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182Gdo6000434; Mon, 7 Feb 2005 18:16:55 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j182GUZP000427; Mon, 7 Feb 2005 18:16:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com ([24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j182FqZJ000372 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 18:16:24 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j182FICi005089 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 21:15:19 -0500 (EST) Message-ID: <42082094.1040905@intertwingly.net> Date: Mon, 07 Feb 2005 21:14:44 -0500 From: Sam Ruby <rubys@intertwingly.net> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: Re: PaceRepeatIdInDocument References: <A3CCE6E2-794D-11D9-88AE-003065EA6144@geckotribe.com> In-Reply-To: <A3CCE6E2-794D-11D9-88AE-003065EA6144@geckotribe.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Antone Roundy wrote: > > -1 (yeah, I know I'm the author) if we define some way to create what > I've recently referred to as Archive Documents. My preferred method is > based on PaceProfile (more on that to come). Also -1 unless there is a way for someone to unambiguously declare that a document may contain multiple versions of of a single element. Even so, I am not convinced that most aggregator authors are up to disambiguating versions. - Sam Ruby From owner-atom-syntax@mail.imc.org Mon Feb 7 22:07:11 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03038 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 22:07:10 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1830T8S004507; Mon, 7 Feb 2005 19:00:29 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1830TYO004506; Mon, 7 Feb 2005 19:00:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1830Tir004499 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 19:00:29 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyLbz-0003wC-G2; Tue, 08 Feb 2005 03:00:23 +0000 Message-ID: <42082B3E.70608@franklinmint.fm> Date: Mon, 07 Feb 2005 22:00:14 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid <eric.scheid@ironclad.net.au> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceHeadless References: <BE2E540B.46C86%eric.scheid@ironclad.net.au> In-Reply-To: <BE2E540B.46C86%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit +1, there's no reason for atom:head. Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 22:13:45 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03416 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 22:13:45 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j183626I004879; Mon, 7 Feb 2005 19:06:02 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18362u8004878; Mon, 7 Feb 2005 19:06:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18361CD004869 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 19:06:01 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyLhM-0003yw-RM; Tue, 08 Feb 2005 03:05:56 +0000 Message-ID: <42082C91.70008@franklinmint.fm> Date: Mon, 07 Feb 2005 22:05:53 -0500 From: Robert Sayre <mint@franklinmint.fm> User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> CC: jasnell@gmail.com, atom-syntax@imc.org Subject: Re: PaceProfile References: <E6A5D29A-795C-11D9-BBC8-003065EA6144@geckotribe.com> <a2b756a2e779b04fc0084eb0edfb1c11@mac.com> <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> <42080C4C.7050708@dehora.net> In-Reply-To: <42080C4C.7050708@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > The problem is that switching on the content of an element/attribute is > Atom's get out of jail card wrt extensibility. It is the default Atom > extensibility model, as it's the only game we have to play that doesn't > involve screwing about with the meaning of existing core data items or > adding new core items. Allowing people to add elements in other > namespaces under atom:feed or atom:entry and calling that extensibility > is like saying a new carpet in my living room is an extension to my > house - it's a crashingly weak approach. So, is that a +1 or a -1 on the profile concept? Robert Sayre From owner-atom-syntax@mail.imc.org Mon Feb 7 22:59:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06584 for <atompub-archive@lists.ietf.org>; Mon, 7 Feb 2005 22:59:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j183mpDu009054; Mon, 7 Feb 2005 19:48:51 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j183mpqE009053; Mon, 7 Feb 2005 19:48:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j183mmd2009043 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 19:48:49 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 16:49:31 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 14:48:45 +1100 Subject: Re: PaceHeadless From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2E81CD.46D4F%eric.scheid@ironclad.net.au> In-Reply-To: <42082B3E.70608@franklinmint.fm> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit -1 atom:feeder is ugly From owner-atom-syntax@mail.imc.org Tue Feb 8 00:14:00 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10752 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 00:14:00 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1853oPd017029; Mon, 7 Feb 2005 21:03:50 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1853oVt017028; Mon, 7 Feb 2005 21:03:50 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1853nJN017006 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 21:03:49 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:54917 "EHLO [217.140.228.50]" TLS-CIPHER: <none>) by smtp2.dnainternet.net with ESMTP id S1228709AbVBHFDe (ORCPT <rfc822;atom-syntax@imc.org>); Tue, 8 Feb 2005 07:03:34 +0200 In-Reply-To: <4207FFDB.1040602@intertwingly.net> References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <p0620070cbe2d5af93b61@[10.20.30.249]> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> <4207FFDB.1040602@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <da48980eb2cbd41bd10a467c34b5fa08@iki.fi> Content-Transfer-Encoding: 7bit Cc: Julian Reschke <julian.reschke@gmx.de>, Anne van Kesteren <fora@annevankesteren.nl>, Atom-Syntax <atom-syntax@imc.org> From: Henri Sivonen <hsivonen@iki.fi> Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 07:03:26 +0200 To: Sam Ruby <rubys@intertwingly.net> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 01:55, Sam Ruby wrote: > Can I get one of you three to mock up what Tim's feed should look like? <a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us'> ... <a:entry> ... <a:content type='XHTML'>I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying <a href='http://dvforge.com/themousebt.shtml'>The Mouse BT</a> from some outfit ... OR <a:feed xmlns:a='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us'> ... <a:entry> ... <a:content type='XHTML'>I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying <h:a href='http://dvforge.com/themousebt.shtml'>The Mouse BT</h:a> from some outfit ... OR <feed xmlns='http://purl.org/atom/ns#draft-ietf-atompub-format-04' version='draft-ietf-atompub-format-04 : do not deploy' xmlns:h='http://www.w3.org/1999/xhtml' xml:lang='en-us'> ... <entry> ... <content type='XHTML'>I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying <h:a href='http://dvforge.com/themousebt.shtml'>The Mouse BT</h:a> from some outfit ... -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 00:45:04 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12562 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 00:45:03 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j185d0Aj021314; Mon, 7 Feb 2005 21:39:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j185d033021313; Mon, 7 Feb 2005 21:39:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j185cxQn021273 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 21:38:59 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 63so21075wri for <atom-syntax@imc.org>; Mon, 07 Feb 2005 21:38:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=hgA+OD1Wdii52y7y/0WMn5zQ078tiXt82VV1p0ePZZi8H1HWH13mtFxJxZJ5PbBXuemrx+Hc9z3rn5jIN14qsZHjXGaR9tOacutJJFWSHV16i0piDeFzkP7O9+KqVbGudW8/cMDCJwBYSfoDR7a7Hh8DRRP2N5d1zZjIiPAjg9E= Received: by 10.54.17.6 with SMTP id 6mr82158wrq; Mon, 07 Feb 2005 21:38:54 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 67sm4575wra.2005.02.07.21.38.53; Mon, 07 Feb 2005 21:38:54 -0800 (PST) Message-ID: <42085066.1050801@gmail.com> Date: Mon, 07 Feb 2005 21:38:46 -0800 From: James M Snell <jasnell@gmail.com> Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid <eric.scheid@ironclad.net.au>, atom-syntax@imc.org Subject: Re: PaceHeadless References: <BE2E81CD.46D4F%eric.scheid@ironclad.net.au> In-Reply-To: <BE2E81CD.46D4F%eric.scheid@ironclad.net.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Agree, feeder is ugly. but head should still go away. My preference would be a link based alternative. <feed> ... <entry> ... <link rel="feed" href="..." /> </entry> </feed> - James M Snell Eric Scheid wrote: > > -1 atom:feeder is ugly > > From owner-atom-syntax@mail.imc.org Tue Feb 8 02:12:27 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29927 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 02:12:27 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1874BoR054527; Mon, 7 Feb 2005 23:04:11 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1874Bq9054526; Mon, 7 Feb 2005 23:04:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1874AW6054318 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 23:04:10 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Tue, 8 Feb 2005 20:04:24 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 08 Feb 2005 18:03:38 +1100 Subject: Re: PaceHeadless From: Eric Scheid <eric.scheid@ironclad.net.au> To: Atom Syntax <atom-syntax@imc.org> Message-ID: <BE2EAF7A.46D78%eric.scheid@ironclad.net.au> In-Reply-To: <42085066.1050801@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8/2/05 4:38 PM, "James M Snell" <jasnell@gmail.com> wrote: > Agree, feeder is ugly. but head should still go away. My preference > would be a link based alternative. > > <feed> > ... > <entry> > ... > <link rel="feed" href="..." /> > </entry> > </feed> +1 From owner-atom-syntax@mail.imc.org Tue Feb 8 02:58:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA12758 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 02:58:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j187e3oQ069903; Mon, 7 Feb 2005 23:40:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j187e3xM069902; Mon, 7 Feb 2005 23:40:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j187e0Oi069759 for <atom-syntax@imc.org>; Mon, 7 Feb 2005 23:40:00 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 13192 invoked by uid 17064); 8 Feb 2005 07:39:52 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.0.53]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <bill@dehora.net>; 8 Feb 2005 07:39:52 -0000 In-Reply-To: <4207F945.4010309@dehora.net> References: <B2F68BC4-7933-11D9-88AE-003065EA6144@geckotribe.com> <705fc547748c3188d295ff7b46288a9c@bblfish.net> <4207F945.4010309@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> Cc: =?ISO-8859-1?Q?Bill_de_h=D3ra?= <bill@dehora.net> From: Henry Story <henry.story@bblfish.net> Subject: Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready Date: Tue, 8 Feb 2005 08:39:28 +0100 To: Atom Syntax <atom-syntax@imc.org> X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j187e0Oi069863 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 8bit If you just want to stick to syntax, then please leave the pace as it is. Don't try to impose a model through syntax and then argue that people can't argue about the model that you are surreptitiously trying to introduce. The current syntax (allowing multiple ids in a feed per feed document) worked very well for both models. Henry Story On 8 Feb 2005, at 00:27, Bill de hÓra wrote: > Henry Story wrote: >> 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 your archive document already. > > Choice of model will not make an iota of difference to the core spec. > I could sit here and claim that sliding window makes reordering > impossible - that would be about as jaundiced and prejudicial a view > as I've seen spat out about current state. What good is this doing? > > Can we please desist from arguing over models? Five years out we can > determine if there is a sufficiently powerful model to explain > syndication based on the data. Not now. > > cheers > Bill > > From owner-atom-syntax@mail.imc.org Tue Feb 8 03:52:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16524 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 03:52:13 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j188hiqh096356; Tue, 8 Feb 2005 00:43:44 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j188hitw096355; Tue, 8 Feb 2005 00:43:44 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mta05-winn.mailhost.ntl.com (smtpout15.mailhost.ntl.com [212.250.162.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j188hgRT096233 for <atom-syntax@imc.org>; Tue, 8 Feb 2005 00:43:43 -0800 (PST) (envelope-from djpowell@djpowell.net) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta05-winn.mailhost.ntl.com with ESMTP id <20050208084322.KOIY1139.mta05-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Tue, 8 Feb 2005 08:43:22 +0000 Received: from cpc3-stke1-5-0-cust2.bagu.cable.ntl.com ([82.11.128.2]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050208084322.VQBC769.aamta05-winn.mailhost.ntl.com@cpc3-stke1-5-0-cust2.bagu.cable.ntl.com>; Tue, 8 Feb 2005 08:43:22 +0000 Date: Tue, 8 Feb 2005 08:43:21 +0000 From: David Powell <djpowell@djpowell.net> X-Mailer: The Bat! (v3.0.2.10) Professional X-Priority: 3 (Normal) Message-ID: <557504842.20050208084321@djpowell.net> To: Eric Scheid <eric.scheid@ironclad.net.au> CC: Atom Syntax <atom-syntax@imc.org> Subject: Re: PaceLangSpecific In-Reply-To: <BE2E569A.46C8B%eric.scheid@ironclad.net.au> References: <4207A5D7.6040704@intertwingly.net> <BE2E569A.46C8B%eric.scheid@ironclad.net.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit Tuesday, February 8, 2005, 12:44:26 AM, you wrote: >> PaceLangSpecific > +1, but also needed for atom:generator > hmmm ... if we have xml:lang on <content>, we are going to also need > @hreflang for <content src="..." />, because while some types of referenced > content can have the language attached, at type="text/plain" cannot. text/plain can have a Content-Language header though - is that compatible with xml:lang? -- Dave From owner-atom-syntax@mail.imc.org Tue Feb 8 05:10:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21968 for <atompub-archive@lists.ietf.org>; Tue, 8 Feb 2005 05:10:59 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189x4fI023885; Tue, 8 Feb 2005 01:59:04 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j189x4vt023884; Tue, 8 Feb 2005 01:59:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j189wud3023854 for <atom-syntax@imc.org>; Tue, 8 Feb 2005 01:58:56 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 64718 invoked by uid 17064); 8 Feb 2005 09:58:56 -0000 Received: from unknown (HELO [192.168.0.3]) ([83.112.0.53]) (envelope-sender <henry.story@bblfish.net>) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for <danbri@w3.org>; 8 Feb 2005 09:58:56 -0000 In-Reply-To: <fb6a3610c51b76f19b5de84f66766691@gbiv.com> References: <BE2CD478.468D1%eric.scheid@ironclad.net.au> <420692FC.6000108@aol.net> <20050206222453.GM16105@homer.w3.org> <a1c85a7e0bc4b5beb9dd691362e2d8d9@gbiv.com> <078e79d17fb53a386484d7ffe8eadcdb@bblfish.net> <5ed187a16ab4416828c4ce7248357447@gbiv.com> <c29f9957fdab2e0f0317be370c6ab00a@bblfish.net> <fb6a3610c51b76f19b5de84f66766691@gbiv.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <904358fd82ee2c87313cc5b194f258e3@bblfish.net> Content-Transfer-Encoding: 7bit Cc: Dan Brickley <danbri@w3.org>, Atom Syntax <atom-syntax@imc.org>, Eric Scheid <eric.scheid@ironclad.net.au>, John Panzer <jpanzer@aol.net>, bloged <users@bloged.dev.java.net> From: Henry Story <henry.story@bblfish.net> Subject: Re: BAG Question: What is a feed? Sliding-Window or Current-State? Date: Tue, 8 Feb 2005 10:58:30 +0100 To: "Roy T. Fielding" <fielding@gbiv.com> X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: <http://www.imc.org/atom-syntax/mail-archive/> List-Unsubscribe: <mailto:atom-syntax-request@imc.org?body=unsubscribe> List-ID: <atom-syntax.imc.org> Content-Transfer-Encoding: 7bit On 8 Feb 2005, at 01:49, Roy T. Fielding wrote: > On Feb 7, 2005, at 5:15 AM, Henry Story wrote: >>>> This is true only if you have the [Equivalence ID] interpretation >>>> of the id relation. (Ie you think of id as equivId.) >>> >>> Yes, and to make myself perfectly clear, that means functional ID, >>> as you call it, would conflict with the design of Atom and any >>> reasonable design of a system wherein the things being identified >>> are allowed to be updated over time. >> >> I wonder if you read the rest of my message... > > Yes, though it seems to me that you swapped the meanings of > funcId and equivId somewhere between your definitions and your > example, so I lost interest. Well I just looked very carefully again at the mail and though I found plenty of places I could have expressed myself better, I did not see any swapping as such take place. >> I gave an example that did not conflict with a reasonable design. > > On the contrary, you gave an example in which a feed contained > two entries with the same id the same funcId to be clear, but two equivIds. It is equivIds that are the ones you are thinking of, and that have the limitations you mention: there cannot be two entries in a feed document that have the same equivId but that are in any other way different, on pain of the document being self contradictory. Hence I did not make a document with two equivId entries. What I wished to show is that you are correct about equivIds, but that another type of id exists (funcIds) that are less strict and that don't have the same consequence. There can be more than one entry in the same feed document with the same functId and with differing content, without there being any contradiction. > (where id here is defined as meaning > the author intends this entry to supplant any prior entries with > the same id). It is not reasonable to include more than > one entry with the same id within the same feed representation, > since all entry representations in the feed representation must > validly represent the state of the feed at the time that the > feed representation was generated (otherwise, it is not a feed > representation at all -- it is an archive, history, ... whatever). Worse!: A document with two entries with the same equivId but different content is inconsistent. It is not an archive, history or anything else. Let me proove this. Consider the following example I used at the end of my lengthy post, but with the funcId replaced by equivIds. <feed>... <entry> <title>Atom-Powered Robots Really Run Amok! vemmi://example.org/2003/32397 2005-02-07T09:30:02Z Atom-Powered Robots Run Amok vemmi://example.org/2003/32397 2003-12-13T18:30:02Z Now let me model this again in arrow notation because it is relatively easy to understand and to visualise (I could do it in prose too, but would be certain to loose your attention before the first sentence) _feed |-entry->_e1 | |--title-> "Atom-Powered Robots Really Run Amok!" | |--equivId-> | |--updated-> "2005-02-07T09:30:02Z" |-entry->_e2 |--title-> "Atom-Powered Robots Run Amok" |--equivId-> |--updated-> "2003-12-13T18:30:02Z" because equivId is an equivalence relation [1], it is reflexive [2] and so for all Entry or Feed objects ef, ef equivId ef. The above graph therefore entails [3] the graph: _feed |-entry-> | |--title-> "Atom-Powered Robots Really Run Amok!" | |--equivId-> | |--updated-> "2005-02-07T09:30:02Z" |-entry-> |--title-> "Atom-Powered Robots Run Amok" |--equivId-> |--updated-> "2003-12-13T18:30:02Z" We can simplify the graph by removing the superfluous equivId statements. _feed |-entry-> | |--title-> "Atom-Powered Robots Really Run Amok!" | |--updated-> "2005-02-07T09:30:02Z" |-entry-> |--title-> "Atom-Powered Robots Run Amok" |--updated-> "2003-12-13T18:30:02Z" And now we since the two groups of entries are speaking about the same resource we can compact the graph down to _feed |-entry-> |--title-> "Atom-Powered Robots Really Run Amok!" |--title-> "Atom-Powered Robots Run Amok" |--updated-> "2003-12-13T18:30:02Z" |--updated-> "2005-02-07T09:30:02Z" Now the problem is that our ontology [4] imposes a restriction on the number of titles and update dates an entry can have. The limitation is: they can only have one. The above assigns them two of each. So if we combine the above graph with the ontology which it is loaded with we have our contradiction. We cannot proceed. If instead of having equivId in the above xml you have funcId then the first entailment is not possible, and so we don't have a contradiction. These are just very different concepts, though they can both correctly be thought of as identifiers. > This whole discussion presumes that it is not desirable to send > all versions of all entries as part of the feed; i.e., the author > specifically intends old versions of an entry to never appear in > later versions of the feed. If you don't agree with that > presumption, then I think you are talking about something other > than what most bloggers call a feed. What I am interested in, as a feed reader, is an automatic way of getting to know about the changes to content that occur on a site. Sometimes I will be interested in the history of changes, sometimes not. Some services will be interested in providing me with the history of changes others not. FuncId allows people to send just the latest version of their site if they wish, or the full list of changes. What is the correct thing to send will depend on the usage of the feed. Why impose an unnecessary limitation? Certainly we are not such slaves to the past that we limit what we do for the sole reason that our ancestors did it that way. >>> So, please, stop trying to >>> make a real system fit an artificial model of graph theory that >>> isn't even capable of describing the Web. Fix your model instead. >> >> Do you have a good paper that proves your incredibly strong statement >> above? I would be happy to understand this position, as it would save >> me a lot of time. > > Okay, but only if you promise not to extend this discussion on > the atom list -- take it elsewhere if you wish to puncture my > opinion -- atom should be allowed to progress in peace without > invoking the defenders of RDF universality. > > : Well I don't want to go into a side discussion on such a topic. I think all I need to point out is that I have been using extremely simple mathematical concepts to do with binary relations [1][2][3] that are very easy to understand. The concept of symmetry, transitivity and reflexivity are taught in France to children age 13. It is clearly within the grasp of any engineer. As with most great ideas, it is the simplicity and clarity of their foundations that enable them to go so far. By the way I very much enjoyed reading your thesis. [5] > Cheers, > > Roy T. Fielding > Chief Scientist, Day Software Henry Story http://bblfish.net/blog/ [1] http://en.wikipedia.org/wiki/Equivalence [2] http://en.wikipedia.org/wiki/Reflexive_relation [3] http://en.wikipedia.org/wiki/Entailment [4] see http://www.intertwingly.net/wiki/pie/AtomOWL but it is also clear from the syntax that these restrictions apply [5] http://www.bblfish.net/blog/page1.html#10 From owner-atom-syntax@mail.imc.org Tue Feb 8 05:49:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24685 for ; Tue, 8 Feb 2005 05:49:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18AerCa038756; Tue, 8 Feb 2005 02:40:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18AerEp038755; Tue, 8 Feb 2005 02:40:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18Aeqab038711 for ; Tue, 8 Feb 2005 02:40:53 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 6695 messnum 2836933 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 10:40:47 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail07.svc.cra.dublin.eircom.net (qp 6695) with SMTP; 8 Feb 2005 10:40:47 -0000 Message-ID: <4208972B.7040209@dehora.net> Date: Tue, 08 Feb 2005 10:40:43 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Atom Syntax Subject: Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready References: <705fc547748c3188d295ff7b46288a9c@bblfish.net> <4207F945.4010309@dehora.net> <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> In-Reply-To: <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Henry Story wrote: > If you just want to stick to syntax, then please leave the pace > as it is. Don't try to impose a model through syntax and then > argue that people can't argue about the model that you are > surreptitiously trying to introduce. Henry, I have no idea what you are talking about. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 8 07:35:06 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04102 for ; Tue, 8 Feb 2005 07:35:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CPmFw078513; Tue, 8 Feb 2005 04:25:48 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CPmB4078512; Tue, 8 Feb 2005 04:25:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18CPkeI078430 for ; Tue, 8 Feb 2005 04:25:47 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 12:25:34 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp026) with SMTP; 08 Feb 2005 13:25:34 +0100 X-Authenticated: #1915285 Message-ID: <4208AFBC.1000706@gmx.de> Date: Tue, 08 Feb 2005 13:25:32 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Anne van Kesteren , Henri Sivonen , Atom-Syntax Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> <4207FFDB.1040602@intertwingly.net> In-Reply-To: <4207FFDB.1040602@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Julian Reschke wrote: > >> >> Anne van Kesteren wrote: >> >>> Henri Sivonen wrote: >>> >>>> -1 on PaceXhtmlNamespaceDiv >>> >>> >>> -1 from me as well. It is hack which might be useful for publishing >>> systems (and perhaps aggregators) who do not use the right tools to >>> generate a valid Atom file anyway. >> >> >> Same here: -1 > > > Can I get one of you three to mock up what Tim's feed should look like? > > http://www.imc.org/atom-syntax/mail-archive/msg12902.html > > - Sam Ruby I'm not sure I understand this request. We're not asking Tim or anybody else not to use
elements, we're asking not to be forced by the spec to select a specific way to emit XHTML when many others do as well. So, this is a -1 on forcing feed creators to use a very specific serialization format. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 07:35:59 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04175 for ; Tue, 8 Feb 2005 07:35:58 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CU0bs080158; Tue, 8 Feb 2005 04:30:00 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CU0JS080157; Tue, 8 Feb 2005 04:30:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CTxpO079957 for ; Tue, 8 Feb 2005 04:30:00 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55076 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228896AbVBHM3n (ORCPT ); Tue, 8 Feb 2005 14:29:43 +0200 In-Reply-To: <4207DBF0.60308@intertwingly.net> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org, Anne van Kesteren From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 14:29:40 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 23:21, Sam Ruby wrote: > 1) Graham (who uses proper XML tools) will have to do more work. Which tools? How much more? One loop more? (FWIW, I do not consider Apple's Core Foundation "XML parser" a proper XML tool.) > 2) Tim (who uses string concatenation) will have to do more work. When I did a string concatenation implementation, using colonified names was not a big deal. > 5) For some combinations of clients and servers, entries produced > via an HTTP POST will end up with multiple
s. I can anticipate that happening either way. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 07:39:40 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04331 for ; Tue, 8 Feb 2005 07:39:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CWgbD081061; Tue, 8 Feb 2005 04:32:42 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CWgGN081060; Tue, 8 Feb 2005 04:32:42 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CWfhJ081013 for ; Tue, 8 Feb 2005 04:32:41 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55081 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228747AbVBHMcg (ORCPT ); Tue, 8 Feb 2005 14:32:36 +0200 In-Reply-To: References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> <4207FFDB.1040602@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: Julian Reschke , Anne van Kesteren , Sam Ruby , Atom-Syntax From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 14:32:32 +0200 To: Henri Sivonen X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 07:03, Henri Sivonen wrote: > > On Feb 8, 2005, at 01:55, Sam Ruby wrote: > >> Can I get one of you three to mock up what Tim's feed should look >> like? > > version='draft-ietf-atompub-format-04 : do not deploy' > xmlns='http://www.w3.org/1999/xhtml' xml:lang='en-us'> > ... > > ... > I was in the drugstore picking up a > prescription and wandered into the computer section, where I found > myself impulse-buying href='http://dvforge.com/themousebt.shtml'>The Mouse BT from some > outfit > ... OR (even less impact on string concatenators): ... ... I was in the drugstore picking up a prescription and wandered into the computer section, where I found myself impulse-buying The Mouse BT from some outfit ... -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 07:43:19 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04530 for ; Tue, 8 Feb 2005 07:43:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Ca35U082230; Tue, 8 Feb 2005 04:36:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Ca3YR082229; Tue, 8 Feb 2005 04:36:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CWfhK081013 for ; Tue, 8 Feb 2005 04:36:02 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55086 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228874AbVBHMgB (ORCPT ); Tue, 8 Feb 2005 14:36:01 +0200 In-Reply-To: <4207D659.7010909@intertwingly.net> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0a97f1a7b69317cbfea52fd196660a17@iki.fi> Content-Transfer-Encoding: 7bit Cc: atom-syntax@imc.org, Anne van Kesteren From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 14:35:58 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 7, 2005, at 22:58, Sam Ruby wrote: > If you are opposed to this pace, then what div element? If the pace does not get through, it is still permissible to put a div in there as part of the content. In fact, either way it is permissible to add meaningless extra divs, since a div can nest in a div. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 07:48:41 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05005 for ; Tue, 8 Feb 2005 07:48:40 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CgcSu084545; Tue, 8 Feb 2005 04:42:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CgcFt084544; Tue, 8 Feb 2005 04:42:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.204]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Cgcnp084535 for ; Tue, 8 Feb 2005 04:42:38 -0800 (PST) (envelope-from danny.ayers@gmail.com) Received: by rproxy.gmail.com with SMTP id 1so50161rny for ; Tue, 08 Feb 2005 04:42:37 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=UmBrjuxuMsriqhQ+b3EUILPjoKSDR/MpRWsk9EWsl9cZoMNomtwEGrPwZp7BalRfKF+dQOZ6Hz3+aYJG9vp4jAvtzcQQjkzyEcVcIRyPw/eFJGj7mFXKWiP1sQ3ZXj8xFiYL4m7Yximr6tLp+yA9RV/ysGzAmHhHcGHDzTjApR0= Received: by 10.38.206.39 with SMTP id d39mr23493rng; Tue, 08 Feb 2005 04:42:37 -0800 (PST) Received: by 10.38.179.46 with HTTP; Tue, 8 Feb 2005 04:42:37 -0800 (PST) Message-ID: <1f2ed5cd05020804425618e666@mail.gmail.com> Date: Tue, 8 Feb 2005 13:42:37 +0100 From: Danny Ayers Reply-To: Danny Ayers To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= Subject: Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready Cc: Atom Syntax In-Reply-To: <4208972B.7040209@dehora.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 References: <705fc547748c3188d295ff7b46288a9c@bblfish.net> <4207F945.4010309@dehora.net> <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> <4208972B.7040209@dehora.net> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18Cgcnp084538 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 08 Feb 2005 10:40:43 +0000, Bill de hÓra wrote: > > Henry Story wrote: > > If you just want to stick to syntax, then please leave the pace > > as it is. Don't try to impose a model through syntax and then > > argue that people can't argue about the model that you are > > surreptitiously trying to introduce. > > Henry, I have no idea what you are talking about. I think all Henry's referring to is the implicit model - only so much is made explicit in the spec. There's the "obvious" containership semantics of XML, there are also plenty of assumptions being made about server/client architectures. Bits over the wire are useless on their own, when semantics are to be attached to them there is benefit in them being standardised through specs. However even if there was the will to define a model, I can't see it happening in the time frame for Atom 1.0. Getting something in an I-D later for RDF-based interop should benefit the core, even without tight spec coupling. But don't let's kid ourselves what we have right now is much more than a syntax and a model with ArchitectureByImplication [1]. 10/10 for the Pace title, btw ;-) Cheers, Danny. [1] http://c2.com/cgi/wiki?ArchitectureByImplication -- http://dannyayers.com From owner-atom-syntax@mail.imc.org Tue Feb 8 07:49:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05086 for ; Tue, 8 Feb 2005 07:49:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CfVDU084154; Tue, 8 Feb 2005 04:41:31 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CfVFs084153; Tue, 8 Feb 2005 04:41:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18CfTKU084105 for ; Tue, 8 Feb 2005 04:41:30 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55098 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228874AbVBHMlY (ORCPT ); Tue, 8 Feb 2005 14:41:24 +0200 In-Reply-To: <557504842.20050208084321@djpowell.net> References: <4207A5D7.6040704@intertwingly.net> <557504842.20050208084321@djpowell.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9312ad0c577c8e8928e1318d9f8cd89e@iki.fi> Content-Transfer-Encoding: 7bit Cc: Atom Syntax , Eric Scheid From: Henri Sivonen Subject: Re: PaceLangSpecific Date: Tue, 8 Feb 2005 14:41:20 +0200 To: David Powell X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 10:43, David Powell wrote: > text/plain can have a Content-Language header though - is that > compatible with > xml:lang? For practical purposes, yes. In theory, the semantics are different. xml:lang specifies the language of the content but Content-Language describes the language of the intended audience. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 07:57:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05421 for ; Tue, 8 Feb 2005 07:57:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Cm3QH086539; Tue, 8 Feb 2005 04:48:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Cm397086538; Tue, 8 Feb 2005 04:48:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18Cm2aq086499 for ; Tue, 8 Feb 2005 04:48:02 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 1617 messnum 3868645 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 12:47:56 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 1617) with SMTP; 8 Feb 2005 12:47:56 -0000 Message-ID: <4208B4F7.5090900@dehora.net> Date: Tue, 08 Feb 2005 12:47:51 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Sayre CC: jasnell@gmail.com, atom-syntax@imc.org Subject: Re: PaceProfile References: <4207FA99.1060007@gmail.com> <4207FD6A.8010301@franklinmint.fm> <42080099.4000506@gmail.com> <42080421.2070502@franklinmint.fm> <42080C4C.7050708@dehora.net> <42082C91.70008@franklinmint.fm> In-Reply-To: <42082C91.70008@franklinmint.fm> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Robert Sayre wrote: > Bill de hÓra wrote: > >> >> The problem is that switching on the content of an element/attribute >> is Atom's get out of jail card wrt extensibility. It is the default >> Atom extensibility model, as it's the only game we have to play that >> doesn't involve screwing about with the meaning of existing core data >> items or adding new core items. Allowing people to add elements in >> other namespaces under atom:feed or atom:entry and calling that >> extensibility is like saying a new carpet in my living room is an >> extension to my house - it's a crashingly weak approach. > > > So, is that a +1 or a -1 on the profile concept? [You mean we have to decide?!?. Now!?!] +1 on the concept. I've seen enough cases in the last week to suggest it's useful. -1 on "@profile" - use an @rel to hold the content instead. I'm not sure whether atom:feed should get an @rel or whether we should use atom:feed/atom:link[@rel]. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 8 08:03:50 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05947 for ; Tue, 8 Feb 2005 08:03:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Cuddi089760; Tue, 8 Feb 2005 04:56:39 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18CudUI089759; Tue, 8 Feb 2005 04:56:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18CublB089707 for ; Tue, 8 Feb 2005 04:56:38 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 12:56:32 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp005) with SMTP; 08 Feb 2005 13:56:32 +0100 X-Authenticated: #1915285 Message-ID: <4208B6FE.1020603@gmx.de> Date: Tue, 08 Feb 2005 13:56:30 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> In-Reply-To: <42080233.5060201@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Sam Ruby wrote: > > Bill de hÓra wrote: > >> Sam Ruby wrote: >> >>> If this Pace is not adopted, the following predictions can be made: >>> >>> 1) Graham (who uses proper XML tools) will have to do more work. I'd like to see a concrete example where this is a problem. As far as I can tell, the content construct itself can be considered the container, so whether or not a mandatory DIV element is present, there will always be a useable container element. >>> 2) Tim (who uses string concatenation) will have to do more work. Nothing changes for Tim, he can continue to produce the output he's producing currently. >>> 3) More feeds will be harder to read (that's why I asked you to >>> experiment with alternate serializations. Whether something is easier to read seems to be a matter of taste: I certainly prefer a globally scoped XHTML namespace declaration, and no additional DIV elements. >>> 3) More feeds will be invalid (content in atom namespace) >> >> >> Perhaps I misunderstand... but this shouldn't result in invalid Atom >> feeds ever - content areas should be able to hold any-namespace not >> any-namespace-atom-namespace. Worst case is mangled content when the >> content is lifted out using namespace aware tools. In other words, the >> container markup format is just dandy, but the content they carry is >> potentially trashed. If we condone default namespaces this is what we >> can expect to happen. We discussed warning people about this broken >> piece of XML technology last year and it was punted to an Implementors >> Guide - I'm somewhat unsympathetic now if we find ourselves bitten. > > > Perhaps I overreached with the word "invalid", but I am of the opinion > that if the type is XHTML that the content should be an xthml fragment. > > atom:b and atom:strong elements are examples of things which one would > not expect to find in xhtml. Yes, but there are many other things people may get wrong when producing Atom. In particular, I would tend to trust those who do generate XHTML instead of HTML to get namespace declarations right as well. Below are some comments that I just added to the Pace: "- Requiring the namespace declaration on a particular element means (a) profiling XMLNS, (b) defeating potential space optimizations by having the namespace declaration only once, and (c) breaks XML toolkits that do not provide full control over where namespace declarations appear. - if this pace gets accepted, I would ask for the same DIV container element for HTML content for reasons of symmetry." Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 08:08:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06391 for ; Tue, 8 Feb 2005 08:08:51 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18D2LAW092037; Tue, 8 Feb 2005 05:02:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18D2LTw092035; Tue, 8 Feb 2005 05:02:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail13.svc.cra.dublin.eircom.net (mail13.svc.cra.dublin.eircom.net [159.134.118.29]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18D2Kd5091979 for ; Tue, 8 Feb 2005 05:02:21 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 6924 messnum 5119697 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 13:02:15 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail13.svc.cra.dublin.eircom.net (qp 6924) with SMTP; 8 Feb 2005 13:02:15 -0000 Message-ID: <4208B852.50500@dehora.net> Date: Tue, 08 Feb 2005 13:02:10 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Danny Ayers CC: Atom Syntax Subject: Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready References: <705fc547748c3188d295ff7b46288a9c@bblfish.net> <4207F945.4010309@dehora.net> <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> <4208972B.7040209@dehora.net> <1f2ed5cd05020804425618e666@mail.gmail.com> In-Reply-To: <1f2ed5cd05020804425618e666@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Danny Ayers wrote: > On Tue, 08 Feb 2005 10:40:43 +0000, Bill de hÓra wrote: > >>Henry Story wrote: >> >>>If you just want to stick to syntax, then please leave the pace >>>as it is. Don't try to impose a model through syntax and then >>>argue that people can't argue about the model that you are >>>surreptitiously trying to introduce. >> >>Henry, I have no idea what you are talking about. > > > I think all Henry's referring to is the implicit model - only so much > is made explicit in the spec. Oh no, is this one of those "do buildings have an intentional or extensional architecture or both" conversations? [I see your link now: yes it is. Damn.] Anyway Henry seems to think I'm trying to impose a model (whatever it is). Otherwise why would he tell not me to impose it? That's why I said I have no idea what he's talking about. Henry, mindreading objection from me. > There's the "obvious" containership > semantics of XML, XML has containership semantics? You jest methinks. > But don't let's kid ourselves what we have right > now is much more than a syntax and a model with > ArchitectureByImplication [1]. Fine, that's all fine - I'm not looking to kid anyone - I just don't care too much about what implicit model people happen to see from day to day, as I don't think it matters much to the format. If people willfully want to polarize themselves over some pet model, then they can have at, but not at the cost of shipping this spec. Has it occured that dragging this WG through an explicit model think-fest might not be helpful at this point? > 10/10 for the Pace title, btw ;-) Thank you. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 8 08:22:13 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07752 for ; Tue, 8 Feb 2005 08:22:12 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DEwEL096779; Tue, 8 Feb 2005 05:14:58 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DEwKA096778; Tue, 8 Feb 2005 05:14:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail07.svc.cra.dublin.eircom.net (mail07.svc.cra.dublin.eircom.net [159.134.118.23]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18DEvUG096733 for ; Tue, 8 Feb 2005 05:14:58 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 23940 messnum 2840022 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 13:14:52 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail07.svc.cra.dublin.eircom.net (qp 23940) with SMTP; 8 Feb 2005 13:14:52 -0000 Message-ID: <4208BB47.1070800@dehora.net> Date: Tue, 08 Feb 2005 13:14:47 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Sam Ruby , Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> In-Reply-To: <4208B6FE.1020603@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: Below are some comments that I just added to the Pace: > > "- Requiring the namespace declaration on a particular element means (a) > profiling XMLNS, I don't have a problem with this. Taking XMLNS warts and all cause more problems that it solves. > (b) defeating potential space optimizations by having > the namespace declaration only once, and Do you have a sense of how serious not allowing these potential optimizations is? > (c) breaks XML toolkits that do > not provide full control over where namespace declarations appear. They sound like dysfunctional toolkits. Can you name some (ie it might be persuasive if it came to light that a scad of PHP users were left high and dry). > - if this pace gets accepted, I would ask for the same DIV container > element for HTML content for reasons of symmetry." +1 to that symmetry. cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 8 08:22:37 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07795 for ; Tue, 8 Feb 2005 08:22:36 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DEPeM096571; Tue, 8 Feb 2005 05:14:25 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DEPqg096570; Tue, 8 Feb 2005 05:14:25 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from bblfish.net (bblfish.net [192.220.66.168]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DEPgZ096562 for ; Tue, 8 Feb 2005 05:14:25 -0800 (PST) (envelope-from henry.story@bblfish.net) Received: (qmail 912 invoked by uid 17064); 8 Feb 2005 13:14:25 -0000 Received: from unknown (HELO [192.168.0.6]) ([83.112.11.147]) (envelope-sender ) by 192.220.66.168 (qmail-ldap-1.03) with SMTP for ; 8 Feb 2005 13:14:25 -0000 In-Reply-To: <1f2ed5cd05020804425618e666@mail.gmail.com> References: <705fc547748c3188d295ff7b46288a9c@bblfish.net> <4207F945.4010309@dehora.net> <1820c5bb2642a7b2f8a6be933d88439d@bblfish.net> <4208972B.7040209@dehora.net> <1f2ed5cd05020804425618e666@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Cc: Atom Syntax , =?ISO-8859-1?Q?Bill_de_h=D3ra?= From: Henry Story Subject: Re: PaceStopArguingAboutSlidingWindowsAndCurrentStateEnoughAlready Date: Tue, 8 Feb 2005 14:13:58 +0100 To: Danny Ayers X-Mailer: Apple Mail (2.619.2) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18DEPgZ096564 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Thanks Danny, that was a good summary. +1 for the title from me too. But I think the deadline for new paces has already passed. >:-> Henry On 8 Feb 2005, at 13:42, Danny Ayers wrote: > On Tue, 08 Feb 2005 10:40:43 +0000, Bill de hÓra > wrote: >> >> Henry Story wrote: >>> If you just want to stick to syntax, then please leave the pace >>> as it is. Don't try to impose a model through syntax and then >>> argue that people can't argue about the model that you are >>> surreptitiously trying to introduce. >> >> Henry, I have no idea what you are talking about. > > I think all Henry's referring to is the implicit model - only so much > is made explicit in the spec. There's the "obvious" containership > semantics of XML, there are also plenty of assumptions being made > about server/client architectures. Bits over the wire are useless on > their own, when semantics are to be attached to them there is benefit > in them being standardised through specs. > > However even if there was the will to define a model, I can't see it > happening in the time frame for Atom 1.0. Getting something in an I-D > later for RDF-based interop should benefit the core, even without > tight spec coupling. But don't let's kid ourselves what we have right > now is much more than a syntax and a model with > ArchitectureByImplication [1]. > > 10/10 for the Pace title, btw ;-) > > Cheers, > Danny. > > [1] http://c2.com/cgi/wiki?ArchitectureByImplication > > > > > > > > > > -- > > http://dannyayers.com > From owner-atom-syntax@mail.imc.org Tue Feb 8 08:52:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09878 for ; Tue, 8 Feb 2005 08:52:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DiIDc003960; Tue, 8 Feb 2005 05:44:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DiIII003959; Tue, 8 Feb 2005 05:44:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DiC39003935 for ; Tue, 8 Feb 2005 05:44:16 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j18Di3kd009186; Tue, 8 Feb 2005 08:44:05 -0500 (EST) Message-ID: <4208C222.3060006@intertwingly.net> Date: Tue, 08 Feb 2005 08:44:02 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Atom-Syntax Subject: Re: PaceXhtmlNamespaceDiv References: <412B23C4.9010602@intertwingly.net> <4130E11B.3000600@intertwingly.net> <41546A46.60507@intertwingly.net> <4166C99A.4040603@intertwingly.net> <41812CA8.6090501@intertwingly.net> <4198C7F6.7040606@intertwingly.net> <41AF672A.60106@intertwingly.net> <41E3E56F.1030209@intertwingly.net> <41E444EB.6030903@intertwingly.net> <41E6D8BC.405@intertwingly.net> <4207A5D7.6040704@intertwingly.net> <61a3227c4c7a7b1060e4a83c2f3bbac4@iki.fi> <4207CAAB.30906@annevankesteren.nl> <4207F48B.9000505@gmx.de> <4207FFDB.1040602@intertwingly.net> <4208AFBC.1000706@gmx.de> In-Reply-To: <4208AFBC.1000706@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > Sam Ruby wrote: > >> Julian Reschke wrote: >>> >>> Anne van Kesteren wrote: >>> >>>> Henri Sivonen wrote: >>>> >>>>> -1 on PaceXhtmlNamespaceDiv >>>> >>>> -1 from me as well. It is hack which might be useful for publishing >>>> systems (and perhaps aggregators) who do not use the right tools to >>>> generate a valid Atom file anyway. >>> >>> Same here: -1 >> >> Can I get one of you three to mock up what Tim's feed should look like? >> >> http://www.imc.org/atom-syntax/mail-archive/msg12902.html >> >> - Sam Ruby > > I'm not sure I understand this request. We're not asking Tim or anybody > else not to use
elements, we're asking not to be forced by the > spec to select a specific way to emit XHTML when many others do as well. > > So, this is a -1 on forcing feed creators to use a very specific > serialization format. This Pace does *not* force feed creators to use a very specific feed format. Anne had this right... if this Pace is adopted, then the div is part of the format. Otherwise, it is part of the content. In other words, if Tim's content has a
element that he wishes to syndicate, he would simply nest that div. This would be rare. As it stands, the content that Tim is syndicating does not match the content on his site. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 8 08:52:21 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09896 for ; Tue, 8 Feb 2005 08:52:21 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DiIIr003961; Tue, 8 Feb 2005 05:44:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DiIWX003958; Tue, 8 Feb 2005 05:44:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DiEwA003937 for ; Tue, 8 Feb 2005 05:44:16 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j18Di9ee019547; Tue, 8 Feb 2005 08:44:10 -0500 (EST) Message-ID: <4208C228.5090709@intertwingly.net> Date: Tue, 08 Feb 2005 08:44:08 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> In-Reply-To: <4208B6FE.1020603@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Julian Reschke wrote: > > Sam Ruby wrote: > >> Bill de hÓra wrote: >> >>> Sam Ruby wrote: >>> >>>> If this Pace is not adopted, the following predictions can be made: >>>> >>>> 1) Graham (who uses proper XML tools) will have to do more work. > > I'd like to see a concrete example where this is a problem. As far as I > can tell, the content construct itself can be considered the container, > so whether or not a mandatory DIV element is present, there will always > be a useable container element. > >>>> 2) Tim (who uses string concatenation) will have to do more work. > > Nothing changes for Tim, he can continue to produce the output he's > producing currently. What Tim is syndicating does not match the content on his site. Without this Pace, the div element would need to be considered part of the content. >>>> 3) More feeds will be harder to read (that's why I asked you to >>>> experiment with alternate serializations. > > Whether something is easier to read seems to be a matter of taste: I > certainly prefer a globally scoped XHTML namespace declaration, and no > additional DIV elements. Fair. However, a globally scoped XHTML namespace declaration will require every xhtml tag to be explicitly namespaced. >>>> 3) More feeds will be invalid (content in atom namespace) >>> >>> Perhaps I misunderstand... but this shouldn't result in invalid Atom >>> feeds ever - content areas should be able to hold any-namespace not >>> any-namespace-atom-namespace. Worst case is mangled content when the >>> content is lifted out using namespace aware tools. In other words, >>> the container markup format is just dandy, but the content they carry >>> is potentially trashed. If we condone default namespaces this is what >>> we can expect to happen. We discussed warning people about this >>> broken piece of XML technology last year and it was punted to an >>> Implementors Guide - I'm somewhat unsympathetic now if we find >>> ourselves bitten. Content type="XML" should be able to hold any type. type="XHTML" should be a valid XHTML fragment. >> Perhaps I overreached with the word "invalid", but I am of the opinion >> that if the type is XHTML that the content should be an xthml fragment. >> >> atom:b and atom:strong elements are examples of things which one would >> not expect to find in xhtml. > > Yes, but there are many other things people may get wrong when producing > Atom. In particular, I would tend to trust those who do generate XHTML > instead of HTML to get namespace declarations right as well. I have personally seen such invalid feeds. In large quanties. I've worked with the individuals that have produced such feeds, but ultimately such an approach doesn't scale. > Below are some comments that I just added to the Pace: > > "- Requiring the namespace declaration on a particular element means (a) > profiling XMLNS, (b) defeating potential space optimizations by having > the namespace declaration only once, and (c) breaks XML toolkits that do > not provide full control over where namespace declarations appear. Nothing in this pace requires such a declaration. > - if this pace gets accepted, I would ask for the same DIV container > element for HTML content for reasons of symmetry." Are you suggesting that the following would need to be required for symmetry? <div> ... </div> Suggesting this seems petty. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 8 08:52:57 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09964 for ; Tue, 8 Feb 2005 08:52:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18De3NZ003608; Tue, 8 Feb 2005 05:40:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18De3lN003607; Tue, 8 Feb 2005 05:40:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from omr5.netsolmail.com (omr5.netsolmail.com [216.168.230.142]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18De2p6003596 for ; Tue, 8 Feb 2005 05:40:02 -0800 (PST) (envelope-from bob@wyman.us) Received: from ms8.netsolmail.com (IDENT:mirapoint@[216.168.230.180]) by omr5.netsolmail.com (8.12.10/8.12.10) with ESMTP id j18Ddpqp029534; Tue, 8 Feb 2005 08:39:55 -0500 (EST) Received: from boblaptop (67.109.101.226.ptr.us.xo.net [67.109.101.226]) by ms8.netsolmail.com (Mirapoint Messaging Server MOS 3.2.2-GA) with ESMTP id COO38386; Tue, 8 Feb 2005 08:39:47 -0500 (EST) Message-Id: <200502081339.COO38386@ms8.netsolmail.com> Reply-To: From: "Bob Wyman" To: , "'Eric Scheid'" , Subject: RE: PaceHeadless Date: Tue, 8 Feb 2005 08:39:42 -0500 Organization: PubSub Concepts, Inc. MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <42085066.1050801@gmail.com> X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-index: AcUNp/t+W9hJvZI9R5+6xqD5fcvRCAAOc3/A Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit James M Snell wrote: > My preference would be a link based alternative. > > ... > > ... > > > I'm tired of arguing this one, so, I'm just going to say this one more time and leave it at that. Linking to the feed is not an acceptable solution. It must be possible to embed feed metadata in an entry in a feed and in an Entry document. Users and their news aggregators expect to have access to source feed title, author, etc. when entries or lists of entries are displayed. If the feed metadata is not in the entries, then it will have to be fetched before entries can be displayed to the user. Thus, we should expect that whenever a feed is received that contains links to feeds, the aggregators will immediately generate a storm of HTTP request to pull down the full feeds which are linked to simply in order to extract the feed titles and other metadata. The result will be bursts of network traffic. Most of the bandwidth consumed will be an absolute waste. (i.e. Many feeds in the wild today are as large as 100K bytes. You're suggesting a design that requires all 100K bytes to be pulled down in order to extract a few bytes of title data. This is silly.) If Atom drops HeadInEntry (or the alternative equivalent mechanisms such as feeder) and replaces it with a link to feed, we at PubSub will simply not be able to use Atom as defined. Other providers of aggregators, search engine results, synthetic feeds, etc. will come to the same conclusion in time. Have a good day. I'm sure you'll all be pleased to know that I won't be bothering you about this in the next few days. Do what you will... bob wyman From owner-atom-syntax@mail.imc.org Tue Feb 8 09:03:51 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10605 for ; Tue, 8 Feb 2005 09:03:50 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Dsa7T004921; Tue, 8 Feb 2005 05:54:36 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DsabO004920; Tue, 8 Feb 2005 05:54:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from pop.ironclad.net.au ([203.30.247.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DsZhw004832 for ; Tue, 8 Feb 2005 05:54:35 -0800 (PST) (envelope-from eric.scheid@ironclad.net.au) Received: from [10.0.1.2] (203.30.247.2) by pop.ironclad.net.au with ESMTP (Eudora Internet Mail Server 1.3.1); Wed, 9 Feb 2005 02:54:52 +1100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 09 Feb 2005 00:54:01 +1100 Subject: Re: PaceXhtmlNamespaceDiv From: Eric Scheid To: Atom Syntax Message-ID: In-Reply-To: <4208B6FE.1020603@gmx.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/2/05 11:56 PM, "Julian Reschke" wrote: > - if this pace gets accepted, I would ask for the same DIV container > element for HTML content for reasons of symmetry." I thought with @type="HTML" the content gets escaped and thus there is nothing to put into a namespace. e. From owner-atom-syntax@mail.imc.org Tue Feb 8 09:04:07 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10655 for ; Tue, 8 Feb 2005 09:04:06 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DttXg005022; Tue, 8 Feb 2005 05:55:55 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DttZn005021; Tue, 8 Feb 2005 05:55:55 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Dts20005008 for ; Tue, 8 Feb 2005 05:55:54 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55232 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228889AbVBHNzh convert rfc822-to-8bit (ORCPT ); Tue, 8 Feb 2005 15:55:37 +0200 In-Reply-To: <4208BB47.1070800@dehora.net> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208BB47.1070800@dehora.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <30802e48898c208d021db4e26ed57586@iki.fi> Content-Transfer-Encoding: 8BIT Cc: Julian Reschke , Anne van Kesteren , atom-syntax@imc.org, Sam Ruby From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 15:55:34 +0200 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8BIT On Feb 8, 2005, at 15:14, Bill de hÓra wrote: > Julian Reschke wrote: > Below are some comments that I just added to the Pace: >> "- Requiring the namespace declaration on a particular element means >> (a) profiling XMLNS, > > I don't have a problem with this. Taking XMLNS warts and all cause > more problems that it solves. Restricting XMLNS is no longer on the table. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 09:07:48 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10919 for ; Tue, 8 Feb 2005 09:07:48 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18DxxA7005410; Tue, 8 Feb 2005 05:59:59 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18DxxaL005409; Tue, 8 Feb 2005 05:59:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18Dxv9w005385 for ; Tue, 8 Feb 2005 05:59:58 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 13:59:50 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp014) with SMTP; 08 Feb 2005 14:59:50 +0100 X-Authenticated: #1915285 Message-ID: <4208C5D4.2000301@gmx.de> Date: Tue, 08 Feb 2005 14:59:48 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208C228.5090709@intertwingly.net> In-Reply-To: <4208C228.5090709@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: >> Nothing changes for Tim, he can continue to produce the output he's >> producing currently. > > > What Tim is syndicating does not match the content on his site. Without > this Pace, the div element would need to be considered part of the content. What difference does this make in practice? HTML defines DIV as... "These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content." () >>>>> 3) More feeds will be harder to read (that's why I asked you to >>>>> experiment with alternate serializations. >> >> >> Whether something is easier to read seems to be a matter of taste: I >> certainly prefer a globally scoped XHTML namespace declaration, and no >> additional DIV elements. > > > Fair. However, a globally scoped XHTML namespace declaration will > require every xhtml tag to be explicitly namespaced. (unless we make it the default namespace, which usually won't make sense). >> "- Requiring the namespace declaration on a particular element means >> (a) profiling XMLNS, (b) defeating potential space optimizations by >> having the namespace declaration only once, and (c) breaks XML >> toolkits that do not provide full control over where namespace >> declarations appear. > > > Nothing in this pace requires such a declaration. "When a Text construct or atom:content's type is "XHTML", require it to have a single xhtml:div as a child, and require that div to declare the XHTML namespace." Am I looking at the wrong pace? () >> - if this pace gets accepted, I would ask for the same DIV container >> element for HTML content for reasons of symmetry." > > > Are you suggesting that the following would need to be required for > symmetry? > > <div> ... </div> Yes. > Suggesting this seems petty. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 09:14:35 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11427 for ; Tue, 8 Feb 2005 09:14:34 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18E4rAB006073; Tue, 8 Feb 2005 06:04:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18E4rXq006072; Tue, 8 Feb 2005 06:04:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18E4p90006057 for ; Tue, 8 Feb 2005 06:04:52 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 14:04:46 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp017) with SMTP; 08 Feb 2005 15:04:46 +0100 X-Authenticated: #1915285 Message-ID: <4208C6FC.9080601@gmx.de> Date: Tue, 08 Feb 2005 15:04:44 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Bill_de_h=D3ra?= CC: Sam Ruby , Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208BB47.1070800@dehora.net> In-Reply-To: <4208BB47.1070800@dehora.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Bill de hÓra wrote: > > Julian Reschke wrote: > Below are some comments that I just added to the Pace: > >> >> "- Requiring the namespace declaration on a particular element means >> (a) profiling XMLNS, > > > I don't have a problem with this. Taking XMLNS warts and all cause more > problems that it solves. Well, it also enables us to relatively painlessly combine Atom and XHTML in the same document. >> (b) defeating potential space optimizations by having the namespace >> declaration only once, and > > > Do you have a sense of how serious not allowing these potential > optimizations is? I just tried with Tim's feed, and I am getting a reduction of around 4%. Your mileage may vary a log depending on typical length and structure of content. >> (c) breaks XML toolkits that do not provide full control over where >> namespace declarations appear. > > They sound like dysfunctional toolkits. Can you name some (ie it might > be persuasive if it came to light that a scad of PHP users were left > high and dry). I wrote one myself back when Xerces' serializer was broken in regards of namespace handling. For the same reasons, similar serializers may exist elsewhere. >> - if this pace gets accepted, I would ask for the same DIV container >> element for HTML content for reasons of symmetry." > > > +1 to that symmetry. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 09:15:02 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11500 for ; Tue, 8 Feb 2005 09:15:02 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18E2vJw005937; Tue, 8 Feb 2005 06:02:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18E2vGZ005936; Tue, 8 Feb 2005 06:02:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18E2u1U005926 for ; Tue, 8 Feb 2005 06:02:57 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55237 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228709AbVBHOCv (ORCPT ); Tue, 8 Feb 2005 16:02:51 +0200 In-Reply-To: <4208C228.5090709@intertwingly.net> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208C228.5090709@intertwingly.net> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <71d59b68715e6214e8da22b70e75157e@iki.fi> Content-Transfer-Encoding: 7bit Cc: Julian Reschke , atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 16:02:48 +0200 To: Sam Ruby X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 15:44, Sam Ruby wrote: > What Tim is syndicating does not match the content on his site. > Without this Pace, the div element would need to be considered part of > the content. What's the harm? > However, a globally scoped XHTML namespace declaration will require > every xhtml tag to be explicitly namespaced. Or the Atom tags to be colonified. > Are you suggesting that the following would need to be required for > symmetry? > > <div> ... </div> > > Suggesting this seems petty. I agree. However, I have similar sentiments towards requiring the div with XHTML. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 09:15:55 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11562 for ; Tue, 8 Feb 2005 09:15:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18E7O4f006270; Tue, 8 Feb 2005 06:07:24 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18E7OBK006269; Tue, 8 Feb 2005 06:07:24 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18E7MLT006254 for ; Tue, 8 Feb 2005 06:07:23 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 14:07:16 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp021) with SMTP; 08 Feb 2005 15:07:16 +0100 X-Authenticated: #1915285 Message-ID: <4208C792.3070608@gmx.de> Date: Tue, 08 Feb 2005 15:07:14 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Scheid CC: Atom Syntax Subject: Re: PaceXhtmlNamespaceDiv References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Eric Scheid wrote: > On 8/2/05 11:56 PM, "Julian Reschke" wrote: > > >>- if this pace gets accepted, I would ask for the same DIV container >>element for HTML content for reasons of symmetry." > > > I thought with @type="HTML" the content gets escaped and thus there is > nothing to put into a namespace. Yes. I think the issue here is that the Pace combines different requirements (a: let's have a single container element, and b: let's force people to explicitly declare their XHTML ns in a single place). It would be good for the discussion if we could agree about what is still in scope, and what in particular we want to achieve. Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 09:34:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12922 for ; Tue, 8 Feb 2005 09:34:19 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18EMLEU007871; Tue, 8 Feb 2005 06:22:21 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18EMLpK007870; Tue, 8 Feb 2005 06:22:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.dnainternet.net (smtp2.dnainternet.net [62.240.72.111]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18EMK6Q007858 for ; Tue, 8 Feb 2005 06:22:21 -0800 (PST) (envelope-from hsivonen@iki.fi) Received: from 217-140-228-50.adsl-net.finnetcom.net ([217.140.228.50]:55262 "EHLO [217.140.228.50]" TLS-CIPHER: ) by smtp2.dnainternet.net with ESMTP id S1228713AbVBHOWP (ORCPT ); Tue, 8 Feb 2005 16:22:15 +0200 In-Reply-To: <4208C5D4.2000301@gmx.de> References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208C228.5090709@intertwingly.net> <4208C5D4.2000301@gmx.de> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <77bc45e7d4d5d19d7adc466e1c886d34@iki.fi> Content-Transfer-Encoding: 7bit Cc: Sam Ruby , atom-syntax@imc.org From: Henri Sivonen Subject: Re: PaceXhtmlNamespaceDiv Date: Tue, 8 Feb 2005 16:22:12 +0200 To: Julian Reschke X-Mailer: Apple Mail (2.619.2) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Feb 8, 2005, at 15:59, Julian Reschke wrote: > "When a Text construct or atom:content's type is "XHTML", require it > to have a single xhtml:div as a child, and require that div to declare > the XHTML namespace." > > Am I looking at the wrong pace? > () The abstract no longer matches the proposal. This seems to cause confusion. -- Henri Sivonen hsivonen@iki.fi http://iki.fi/hsivonen/ From owner-atom-syntax@mail.imc.org Tue Feb 8 09:41:29 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13365 for ; Tue, 8 Feb 2005 09:41:29 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18EUulN008684; Tue, 8 Feb 2005 06:30:56 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18EUuIK008683; Tue, 8 Feb 2005 06:30:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18EUtot008674 for ; Tue, 8 Feb 2005 06:30:55 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j18EUoee010623; Tue, 8 Feb 2005 09:30:51 -0500 (EST) Message-ID: <4208CD1A.6090006@intertwingly.net> Date: Tue, 08 Feb 2005 09:30:50 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208C228.5090709@intertwingly.net> <4208C5D4.2000301@gmx.de> In-Reply-To: <4208C5D4.2000301@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: >>> "- Requiring the namespace declaration on a particular element means >>> (a) profiling XMLNS, (b) defeating potential space optimizations by >>> having the namespace declaration only once, and (c) breaks XML >>> toolkits that do not provide full control over where namespace >>> declarations appear. >> >> Nothing in this pace requires such a declaration. > > "When a Text construct or atom:content's type is "XHTML", require it to > have a single xhtml:div as a child, and require that div to declare the > XHTML namespace." > > Am I looking at the wrong pace? > () I have just updated the Pace to remove from the abstract text which is no longer reflected in the proposal. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 8 09:45:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13679 for ; Tue, 8 Feb 2005 09:45:53 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18EaItW009206; Tue, 8 Feb 2005 06:36:19 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18EaIIL009205; Tue, 8 Feb 2005 06:36:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18EaHcO009195 for ; Tue, 8 Feb 2005 06:36:18 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 14:36:11 -0000 Received: from p50825F85.dip0.t-ipconnect.de (EHLO [192.168.1.40]) (80.130.95.133) by mail.gmx.net (mp008) with SMTP; 08 Feb 2005 15:36:11 +0100 X-Authenticated: #1915285 Message-ID: <4208CE5B.5050203@gmx.de> Date: Tue, 08 Feb 2005 15:36:11 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: atom-syntax@imc.org Subject: type=HTML Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit () The spec currently says: "If the value of "type" is "HTML", the content of the Text construct MUST NOT contain child elements, and SHOULD be suitable for handling by software that knows HTML. The HTML markup must be escaped; for example, "
" as "<br>". The HTML markup SHOULD be such that it could validly appear directly within an HTML
element. Receiving software which displays the content MAY use the markup to aid in displaying it." Is there anything that we can say about what recipients should do if they are not prepared to tag-soup-parse HTML content (such as something based on XSLT1 in Mozilla or running in a size-constrained environment (does MIDP come with an HTML parser)? Skip the entry? Do not display the content? Display the content including the escaped markup as plain text? Shouldn't we at least give content producers the hint that producing XHTML content is preferred over HTML? (sorry if I'm opening a can of worms here) Best regards, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From owner-atom-syntax@mail.imc.org Tue Feb 8 10:52:44 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19591 for ; Tue, 8 Feb 2005 10:52:44 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18FYhou014477; Tue, 8 Feb 2005 07:34:43 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18FYhob014476; Tue, 8 Feb 2005 07:34:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from smtp2.versatel.nl (smtp2.versatel.nl [62.58.50.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18FYfNp014448 for ; Tue, 8 Feb 2005 07:34:42 -0800 (PST) (envelope-from fora@annevankesteren.nl) Received: (qmail 14842 invoked by uid 10); 8 Feb 2005 15:34:29 -0000 Received: (vexira-qq 14836-5DE9938 invoked from network) 08 Feb 2005 16:34:29 +0100 Received: from unknown (HELO [127.0.0.1]) ([81.59.139.118]) (envelope-sender ) by smtp2.versatel.nl (qmail-ldap-1.03) with SMTP for < >; 8 Feb 2005 15:34:29 -0000 Message-ID: <4208DC05.90804@annevankesteren.nl> Date: Tue, 08 Feb 2005 16:34:29 +0100 From: Anne van Kesteren User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> <4208C228.5090709@intertwingly.net> In-Reply-To: <4208C228.5090709@intertwingly.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.100; host: postbode02.zonnet.nl) Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > Content type="XML" should be able to hold any type. type="XHTML" should > be a valid XHTML fragment. I hope type="XML" is just an example? (I still think we should revert it back to TYPE and MODE where MODE is optional and TYPE has a fixed value of "text/plain".) -- Anne van Kesteren From owner-atom-syntax@mail.imc.org Tue Feb 8 10:52:56 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19649 for ; Tue, 8 Feb 2005 10:52:56 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18FhIOW015176; Tue, 8 Feb 2005 07:43:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18FhInm015175; Tue, 8 Feb 2005 07:43:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from ms-smtp-04-eri0.southeast.rr.com (ms-smtp-04-lbl.southeast.rr.com [24.25.9.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18FhGYH015167 for ; Tue, 8 Feb 2005 07:43:17 -0800 (PST) (envelope-from rubys@intertwingly.net) Received: from [127.0.0.1] (rdu57-27-065.nc.rr.com [66.57.27.65]) by ms-smtp-04-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j18Fh7Ci029116; Tue, 8 Feb 2005 10:43:08 -0500 (EST) Message-ID: <4208DE0A.10303@intertwingly.net> Date: Tue, 08 Feb 2005 10:43:06 -0500 From: Sam Ruby User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: atom-syntax@imc.org Subject: Re: type=HTML References: <4208CE5B.5050203@gmx.de> In-Reply-To: <4208CE5B.5050203@gmx.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Symantec AntiVirus Scan Engine Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > () > > The spec currently says: > > "If the value of "type" is "HTML", the content of the Text construct > MUST NOT contain child elements, and SHOULD be suitable for handling by > software that knows HTML. The HTML markup must be escaped; for example, > "
" as "<br>". The HTML markup SHOULD be such that it could > validly appear directly within an HTML
element. Receiving software > which displays the content MAY use the markup to aid in displaying it." > > Is there anything that we can say about what recipients should do if > they are not prepared to tag-soup-parse HTML content (such as something > based on XSLT1 in Mozilla or running in a size-constrained environment > (does MIDP come with an HTML parser)? Skip the entry? Do not display the > content? Display the content including the escaped markup as plain text? I would suggest stripping the tags. In Perl, something like this: s/<.*?>//g > Shouldn't we at least give content producers the hint that producing > XHTML content is preferred over HTML? (sorry if I'm opening a can of > worms here) Depending on the target environment, stripping the elements in XHTML may also be appropriate. - Sam Ruby From owner-atom-syntax@mail.imc.org Tue Feb 8 11:08:05 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20716 for ; Tue, 8 Feb 2005 11:08:05 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18G1cpG016942; Tue, 8 Feb 2005 08:01:38 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18G1ccp016941; Tue, 8 Feb 2005 08:01:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18G1cXJ016925 for ; Tue, 8 Feb 2005 08:01:38 -0800 (PST) (envelope-from antone@geckotribe.com) Received: from geckotribe.com (c-24-10-235-185.client.comcast.net[24.10.235.185]) by comcast.net (rwcrmhc12) with SMTP id <20050208160133014003b3f1e>; Tue, 8 Feb 2005 16:01:33 +0000 Date: Tue, 8 Feb 2005 09:01:31 -0700 Subject: Re: PaceProfile Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v553) From: Antone Roundy To: atom-syntax@imc.org In-Reply-To: <4208B4F7.5090900@dehora.net> Message-Id: X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18G1cXJ016936 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tuesday, February 8, 2005, at 05:47 AM, Bill de hÓra wrote: > Robert Sayre wrote: >> Bill de hÓra wrote: >>> >>> The problem is that switching on the content of an element/attribute >>> is Atom's get out of jail card wrt extensibility. It is the default >>> Atom extensibility model, as it's the only game we have to play that >>> doesn't involve screwing about with the meaning of existing core >>> data items or adding new core items. Allowing people to add elements >>> in other namespaces under atom:feed or atom:entry and calling that >>> extensibility is like saying a new carpet in my living room is an >>> extension to my house - it's a crashingly weak approach. >> So, is that a +1 or a -1 on the profile concept? > > [You mean we have to decide?!?. Now!?!] > > +1 on the concept. I've seen enough cases in the last week to suggest > it's useful. > > -1 on "@profile" - use an @rel to hold the content instead. I'm not > sure whether atom:feed should get an @rel or whether we should use > atom:feed/atom:link[@rel]. > -1 to using naming it @rel. wouldn't make any sense at all--"The feed's relationship is 'core'." Relationship to what? ... likewise makes no sense--what are you going to put in @href? From owner-atom-syntax@mail.imc.org Tue Feb 8 11:26:28 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21946 for ; Tue, 8 Feb 2005 11:26:28 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18GGrhK018524; Tue, 8 Feb 2005 08:16:53 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18GGrwE018523; Tue, 8 Feb 2005 08:16:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail08.svc.cra.dublin.eircom.net (mail08.svc.cra.dublin.eircom.net [159.134.118.24]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18GGqnP018510 for ; Tue, 8 Feb 2005 08:16:52 -0800 (PST) (envelope-from bill@dehora.net) Received: (qmail 5302 messnum 3862795 invoked from network[83.70.164.213/83-70-164-213.b-ras1.prp.dublin.eircom.net]); 8 Feb 2005 16:16:46 -0000 Received: from 83-70-164-213.b-ras1.prp.dublin.eircom.net (HELO ?192.168.123.143?) (83.70.164.213) by mail08.svc.cra.dublin.eircom.net (qp 5302) with SMTP; 8 Feb 2005 16:16:46 -0000 Message-ID: <4208E5E9.4040208@dehora.net> Date: Tue, 08 Feb 2005 16:16:41 +0000 From: =?ISO-8859-1?Q?Bill_de_h=D3ra?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Antone Roundy CC: atom-syntax@imc.org Subject: Re: PaceProfile References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Antone Roundy wrote: > > On Tuesday, February 8, 2005, at 05:47 AM, Bill de hÓra wrote: > >> [You mean we have to decide?!?. Now!?!] >> >> +1 on the concept. I've seen enough cases in the last week to suggest >> it's useful. >> >> -1 on "@profile" - use an @rel to hold the content instead. I'm not >> sure whether atom:feed should get an @rel or whether we should use >> atom:feed/atom:link[@rel]. >> > -1 to using naming it @rel. wouldn't make any sense > at all--"The feed's relationship is 'core'." Relationship to what? > ... likewise makes no sense-- That nicely sums up the feelings I have had about @rel. It's a bucket for putting switches into - the implied dispatching is the same whatever it's called. Why can't @rel be short for @relevance? cheers Bill From owner-atom-syntax@mail.imc.org Tue Feb 8 12:08:39 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25658 for ; Tue, 8 Feb 2005 12:08:39 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Gv9DI021280; Tue, 8 Feb 2005 08:57:09 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Gv97b021279; Tue, 8 Feb 2005 08:57:09 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Gv4DJ021269 for ; Tue, 8 Feb 2005 08:57:04 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-0cdfl1u.cable.mindspring.com ([24.215.212.62] helo=[192.168.1.101]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1CyYfa-0004wN-54; Tue, 08 Feb 2005 16:56:58 +0000 Message-ID: <4208EF59.20809@franklinmint.fm> Date: Tue, 08 Feb 2005 11:56:57 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: Julian Reschke , atom-syntax@imc.org Subject: Re: type=HTML References: <4208CE5B.5050203@gmx.de> <4208DE0A.10303@intertwingly.net> In-Reply-To: <4208DE0A.10303@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > >> Shouldn't we at least give content producers the hint that producing >> XHTML content is preferred over HTML? (sorry if I'm opening a can of >> worms here) > > > Depending on the target environment, stripping the elements in XHTML may > also be appropriate. I would strip both unless the phone had an HTML component available. There are plenty RSS readers for phones and small devices, so this doesn't seem to be a problem. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 8 12:32:52 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27335 for ; Tue, 8 Feb 2005 12:32:52 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HMkvr023101; Tue, 8 Feb 2005 09:22:46 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18HMkpI023100; Tue, 8 Feb 2005 09:22:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mx1.verity.com (mx1.verity.com [192.187.147.8]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HMjKb023090 for ; Tue, 8 Feb 2005 09:22:46 -0800 (PST) (envelope-from wunder@verity.com) Received: from soda.verity.com (soda [10.3.100.96]) by postal.verity.com (Postfix) with ESMTP id E83FBC4 for ; Tue, 8 Feb 2005 09:22:34 -0800 (PST) Received: from [192.168.150.112] (diva.verity.com [192.168.150.112]) by soda.verity.com (8.12.6/8.12.6) with ESMTP id j18HMYLf008007 for ; Tue, 8 Feb 2005 09:22:34 -0800 (PST) Date: Tue, 08 Feb 2005 09:42:20 -0800 From: Walter Underwood To: atom-syntax@imc.org Subject: RE: PaceHeadless Message-ID: In-Reply-To: <200502081339.COO38386@ms8.netsolmail.com> References: <200502081339.COO38386@ms8.netsolmail.com> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman wrote: > > Linking to the feed is not an acceptable solution. It must be > possible to embed feed metadata in an entry in a feed and in an Entry > document. +1 The feed document *must* be standalone. Everything required to interpret the feed has to be in the feed. wunder -- Walter Underwood Principal Architect Verity Ultraseek From owner-atom-syntax@mail.imc.org Tue Feb 8 12:51:42 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29166 for ; Tue, 8 Feb 2005 12:51:42 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HbIsc023822; Tue, 8 Feb 2005 09:37:18 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18HbIFm023821; Tue, 8 Feb 2005 09:37:18 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.205]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18HbH5j023811 for ; Tue, 8 Feb 2005 09:37:18 -0800 (PST) (envelope-from jasnell@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so1918481wri for ; Tue, 08 Feb 2005 09:37:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:organization:user-agent:x-accept-language:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; b=LREJh9LEmRhROC5z2C9zWSK349XLxXAlck+eO9a834Dt8PsAuvKjPJsTG8wpiGercfJmNMZHh1drjwQYJ2uG5DgCxJ44mNPRehT+zsS653ywQcsXSvhq50l3TUgWsar46Sf+csGo06F2g3My/kKjxtHYtx+yUcG6Shnwj3TmL7k= Received: by 10.54.50.31 with SMTP id x31mr27823wrx; Tue, 08 Feb 2005 09:37:12 -0800 (PST) Received: from ?192.168.1.101? ([67.181.223.222]) by smtp.gmail.com with ESMTP id 65sm162569wra.2005.02.08.09.37.11; Tue, 08 Feb 2005 09:37:12 -0800 (PST) Message-ID: <4208F8C1.7080900@gmail.com> Date: Tue, 08 Feb 2005 09:37:05 -0800 From: James M Snell Reply-To: jasnell@gmail.com Organization: http://www.snellspace.com User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Walter Underwood , atom-syntax@imc.org Subject: Re: PaceHeadless References: <200502081339.COO38386@ms8.netsolmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Well, I ain't gonna argue the point, but I'm going to stick by the assertion that feeder/head is ugly. Any use of this stuff I plan to make can live equally well with either approach. - James M Snell Walter Underwood wrote: > > --On Tuesday, February 08, 2005 08:39:42 AM -0500 Bob Wyman > wrote: > >> >> Linking to the feed is not an acceptable solution. It must be >> possible to embed feed metadata in an entry in a feed and in an Entry >> document. > > > +1 > > The feed document *must* be standalone. Everything required to > interpret the feed has to be in the feed. > > wunder > -- > Walter Underwood > Principal Architect > Verity Ultraseek > > From owner-atom-syntax@mail.imc.org Tue Feb 8 13:44:54 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03575 for ; Tue, 8 Feb 2005 13:44:54 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18ISvdg027384; Tue, 8 Feb 2005 10:28:57 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18ISvvB027383; Tue, 8 Feb 2005 10:28:57 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from web02.designerslab.net (sparky.co.za [66.98.134.28] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18ISuim027377 for ; Tue, 8 Feb 2005 10:28:56 -0800 (PST) (envelope-from mint@franklinmint.fm) Received: from user-12lcgog.cable.mindspring.com ([69.86.67.16] helo=[192.168.0.7]) by web02.designerslab.net with esmtpa (Exim 4.43) id 1Cya6M-0005n4-4H; Tue, 08 Feb 2005 18:28:42 +0000 Message-ID: <420904D8.7050203@franklinmint.fm> Date: Tue, 08 Feb 2005 13:28:40 -0500 From: Robert Sayre User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Julian Reschke CC: Sam Ruby , =?ISO-8859-1?Q?Bill_de_h=D3ra?= , Anne van Kesteren , atom-syntax@imc.org Subject: Re: PaceXhtmlNamespaceDiv References: <4207CD2C.4090608@gmail.com> <4207CEBF.10206@annevankesteren.nl> <4207D659.7010909@intertwingly.net> <4207D735.6080809@annevankesteren.nl> <4207DBF0.60308@intertwingly.net> <4207FFFA.6050503@dehora.net> <42080233.5060201@intertwingly.net> <4208B6FE.1020603@gmx.de> In-Reply-To: <4208B6FE.1020603@gmx.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - web02.designerslab.net X-AntiAbuse: Original Domain - imc.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [47 12] X-AntiAbuse: Sender Address Domain - franklinmint.fm Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Julian Reschke wrote: > > - if this pace gets accepted, I would ask for the same DIV container > element for HTML content for reasons of symmetry." I'm sorry, that is ridiculous. Robert Sayre From owner-atom-syntax@mail.imc.org Tue Feb 8 13:45:20 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03709 for ; Tue, 8 Feb 2005 13:45:20 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IdsN7027905; Tue, 8 Feb 2005 10:39:54 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IdsJD027904; Tue, 8 Feb 2005 10:39:54 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IdrwT027892 for ; Tue, 8 Feb 2005 10:39:53 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j18IdW0D000656; Tue, 8 Feb 2005 18:39:32 GMT In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2c022640a7cfc2d70d4f70c6c72e1a2f@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom Syntax From: Graham Subject: Re: PaceArchiveDocument Date: Tue, 8 Feb 2005 18:39:33 +0000 To: Eric Scheid X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 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 From owner-atom-syntax@mail.imc.org Tue Feb 8 13:56:18 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04576 for ; Tue, 8 Feb 2005 13:56:17 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Id38V027871; Tue, 8 Feb 2005 10:39:03 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Id3sk027870; Tue, 8 Feb 2005 10:39:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from brookes.ac.uk (csmail1.brookes.ac.uk [161.73.1.23]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Id2a1027861 for ; Tue, 8 Feb 2005 10:39:03 -0800 (PST) (envelope-from dtcd@mac.com) Received: from [10.0.1.2] (data-csmail2 [192.168.2.2]) by brookes.ac.uk (8.12.11/8.12.11) with ESMTP id j18IcKbL000132; Tue, 8 Feb 2005 18:38:20 GMT In-Reply-To: <4207B014.5000200@franklinmint.fm> References: <4207B014.5000200@franklinmint.fm> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8154c529fd2e9f3822a1514c3193421a@mac.com> Content-Transfer-Encoding: 7bit Cc: Atom-Syntax From: Graham Subject: Re: PaceDatesXSD Date: Tue, 8 Feb 2005 18:38:20 +0000 To: Robert Sayre X-Mailer: Apple Mail (2.619.2) X-MailScanner-Information: Oxford Brookes University MailScanner X-MailScanner: Clean X-MailScanner-From: dtcd@mac.com Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -1 on the regex. It's completely unreadable and hides whatever additional constraints it adds. Write those down in English please. Graham From owner-atom-syntax@mail.imc.org Tue Feb 8 14:45:36 2005 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08221 for ; Tue, 8 Feb 2005 14:45:35 -0500 (EST) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18JMn8C030852; Tue, 8 Feb 2005 11:22:49 -0800 (PST) (envelope-from owner-atom-syntax@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18JMnTn030851; Tue, 8 Feb 2005 11:22:49 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-atom-syntax@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18JMdUK030829 for ; Tue, 8 Feb 2005 11:22:40 -0800 (PST) (envelope-from julian.reschke@gmx.de) Received: (qmail invoked by alias); 08 Feb 2005 19:22:28 -0000 Received: from pD9E5162A.dip.t-dialin.net (EHLO [192.168.0.2]) (217.229.22.42) by mail.gmx.net (mp018) with SMTP; 08 Feb 2005 20:22:28 +0100 X-Authenticated: #1915285 Message-ID: <42091171.4070203@gmx.de> Date: Tue, 08 Feb 2005 20:22:25 +0100 From: Julian Reschke User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Ruby CC: atom-syntax@imc.org Subject: Re: type=HTML References: <4208CE5B.5050203@gmx.de> <4208DE0A.10303@intertwingly.net> In-Reply-To: <4208DE0A.10303@intertwingly.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-atom-syntax@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Sam Ruby wrote: > > Julian Reschke wrote: > >> >> () >> >> The spec currently says: >> >> "If the value of "type" is "HTML", the content of the Text construct >> MUST NOT contain child elements, and SHOULD be suitable for handling >> by software that knows HTML. The HTML markup must be escaped; for >> example, "
" as "<br>". The HTML markup SHOULD be such that it >> could validly appear directly within an HTML
element. Receiving >> software which displays the content MAY use the markup to aid in >> displaying it." >> >> Is there anything that we can say about what recipients should do if >> they are not prepared to tag-soup-parse HTML content (such as >> something based on XSLT1 in Mozilla or running in a size-constrained >> environment (does MIDP come with an HTML parser)? Skip the entry? Do >> not display the content? Display the content including the escaped >> markup as plain text? > > > I would suggest stripping the tags. In Perl, something like this: > > s/<.*?>//g Thanks. Are we 100% confident that whatever results from that replacement can be safely embedded? For instance, what about